I have a project with a RESTful Rails back-end and a Flex front-end, first time for me with this combo and I debating whether to put the flex source somewhere inside the Rails folder hierarchy or making it a separate project. If I do so which folder would be most suitable /lib?
Also be doing one click deployment with Vlad which can also compile the flex app and dump it in the public folder.
Or does anyone have any good reasons why the flex project shouldn't reside within the Rails folder hierarchy?
Cheers
From personal experience, it's fine in the Rails folder structure. We have a "/flexsrc" folder a the rails project level in git, and when we build, the swf and related files are dumped to the /public area. It's been this way for a while, and there's no apparent drawback.
I think it would be more of a hassle to have two source depots.
(disclaimer, I've only used Flex with PHP and Java, I'm not terribly familiar with Rails so I can only really address the last part of the question).
My general experience is that it is best to keep both Flex and its hosting server components in the same source tree and svn project. Unless you have reason to believe that you are going to need a different server at some point, I can't really imagine any reason why you wouldn't want to:
Keeping them in the same project makes it easier to automate builds (in Java definitely, and it sounds the same in Rails).
If they are in the same tree, then it is easier for other developers to work on the same code without using SVN externals.
Placing them as separate projects can complicate compiler arguments for RemoteObjects and the like
This is the way I do it:
AppRepo
FlexAppFolder/
RailsAppFolder/
I like the Glenn's approach, but as ChrisInCambo said he's using a RESTful Rails back-end, which means that Rails has a bunch of services to expose and which means that the services could be consumed from different clients (front-ends), maybe not now, but in a future.
Another approach could be
RailsAppRepo
FlexAppRepo
and if you're using git you can do:
git submodule add backend git://your_backend_repo
or an svn external
Any ideas?
Related
I've created a web app (mvc4) that I'd like to reuse in multiple projects. The site is an admin panel, but it may be extended and slightly modified in each project. I want to avoid copying the project over, because I'd like to be able to update each project to the latest version at the lowest possible cost.
So far I have tried 2 approaches:
a script that 'clones' the project by copying all the necessary things as well as altering others (guids in assemblies, namespaces and things like that) - this works fine for extensibility and modification, but that's just a copy so pushing 'updates' is a mess (I did it manually) and it does not scale.
portable areas from mvc contrib project - this seemed like a good idea at first, but it turns out that it's nice for simple scenarios, but fails at more advanced use cases. It doesn't support localization (from resources embedded in the portable area), bundling and min requires a lot of hacks (mvc contrib is still on mvc 3), it's not possible (out of the box) to reuse shared views or Display/Editor templates from the portable area and it looks like if I'd go further that way, some new things would come up
Currently I'm thinking about 'just' branching each project from the core one. This would of course require the same changes (or at least a big subset of them) that were done in the script I mentioned earlier, and I'm afraid that if I try to pull updates from the core project the number of conflicts will render the whole approach unusable.
Does anyone have an idea on how I could tackle this problem?
I'd suggest to create a NuGet package of the mvc app and reuse it. So versioning and applying updates would be much easier. However it takes a bit work to make your code completely isolated from the codes you want to add in the new project.
I've been developing a web application and a lot of customers are asking if they can host the application in their network (for security reasons). I have been looking for a way to package up a rails app into a single executable (with server and all), but haven't been able to find anything. My other requirement is that we distribute it without the source. Because of that I was looking at JRuby and Warbler. The end product should run on linux or windows. Has anyone done anything like this before, or can anyone point me in the right direction.
Thanks
My best guess would be to use JRuby and the JRubyCompiler, although I have no idea if you could compile a whole rails project (including all the required gems). I got it to compile a small ruby script though. Anyway, if you succeed, you could package those in a jar or war and deploy that as a contained application.
It doesn't sound like you necessarily need to package it as an executable, as long as the code is obfuscated. I personally haven't needed to protect any of my code, but a quick google search returned this product http://rubyencoder.com/. I'm sure there are others out there, but the basic idea is that your code is unreadable and cannot be reverse engineered. This would allow you to run a standard rails environment without giving access to your source code.
If you have the budget and really want to outsource this, the Github guys partnered with BitRock to build their cross-platform installable product (Github Firewall Install). BitRock has this case study on their website.
Ok, please bear with my noob question here.
I'm doing the simple task of making an update to my mvc application, compiling it and then moving in onto the production server.
I just wan't to know the best way to upload the compiled files. I have a single application pool, use ftp to upload the new application files and the site points to a single directory.
If I update just one view then which
files do I upload after compiling?
Is there a way to keep the site running
while I upload new code/views?
Where can I go to find out this
information?
Generally, you can update views without needing to re-cycle your web application. You would just want to replace the old version of the file with the new version, which can be done with a simple X-Copy command.
If there are code changes, then you will need to upate the web project DLL, which requires the app to recycle. This may or may not be a huge disruption, but it does mean that users may have their session interrupted, and lose some state.
Now, the question of how you could go about doing this is a little more complex. You can write a deployment process into your build scripts, which may be the easiest approach. The trick here, though, is that if you want to only include files that have changed, this can be a little trickier using vanilla NAnt or MSBuild tasks. You may also want to look at the WebDeploy tool from the IIS team. I've not used it much myself, but it is designed specifically to deploy web projects.
You may also want to hit google for some commercial deployment tools if none of the options so far seem to work for you.
It has been a long while since I have really worked with J2EE so please excuse my ignorance. My recent engagement in a Grails project has peaked my interest in Java once more and especially in Grails as it makes building web applications on the Java platform fun again. That being said, I would like an expert to comment on the following requirement that I have for an application built using Grails:
The Design Team (web designers) require access to the GSP pages and edit the view files (layouts, templates, etc.) without bothering the development team (software developers). This scenario can take place both during construction and after deployment into production.
The communication level between the Designers, Developers, and Business Users are not an issue here. However, about 40% of the time, the Business Units involved request changes to the front-end that have no impact on the Developers time but require the time of a Design Team member. Currently, the deployment workflow follows the Grails application through the deployment of a War file to a Tomcat server. I imagine there is a simpler way to allow the Design team to make UI changes without going through the build and deploy lifecycle.
Several of the Design Team members have had exposure to PHP in the past and at times miss the ability to just overwrite a template file to make a UI piece more functional or improve a layout template. I hope there is a similar way to accommodate such simplicity within Grails. I have been told that exploding the War file might be an option but that still requires the reload of the Tomcat hosted application.
If you believe that I looking at the desired solution the wrong way, please do chime in as I am more interested in a workable compromise for all the team members involved. Thank you.
You need to specify the following settings in Config.groovy:
grails.gsp.enable.reload=true
grails.gsp.view.dir="/path/to/gsp/views"
The 'grails.gsp.view.dir' is typically the path to your checked out SVN repo. You can then just 'svn up' everytime you want to update the views.
There is one caveat: When a GSP view is compiled it uses up permgen. Eventually you will run out and need to restart the server.
You could run a server with a version of the application via run-app in development mode. The designers can then make changes to the views and they will reload. They would need to be able to acccess the source code on the server via a share of some kind. As a plus, if you checked out the source the designers could then commit their changes from the server.
The downside is that if the reloading fails or you run out of memory (has been known to happen with lots of reloading) either a developer would need to stop and start the app or you could provide the designers with a script to run to bounce it.
You'd obviously take a performance hit by running in development mode and via run-app but it might a ok trade off in your case.
cheers
Lee
This may not be the direct answer for this question but since you seem to pay attention to designers' role in a project, you may also check my designer friendly GSP implementation which enables designers to view GSP pages even with custom tags thanks to the "tag declaration via attributes" feature.
I'm considering developing aspects of a website as Rails plugins for reuse. My question is about the development process. Since each of these plugins will provide a "slice" of functionality, should I develop each "slice" as it's own application and then extract the code from each application into a plugin? Or, should I write them as plugins right in an application? Ultimately I will be linking to these plugins from each site to keep it DRY.
I guess the main question is what would be the development process for creating multiple "Engine" type plugins?
Thanks in advance for any help.
Either approach is valid.
When writing a basic plugin I usually find it easier to write it in tandem with the application that will use it. Because I find it easier to design/test around something that already exists.
However, when it comes to Engine plugins, I prefer to develop them as a separate application and then rip out all the unnecessary bits when I move it into a plugin. They are in essence mini applications, and they should be completely functional when installed on a freshly created rails project.
By designing them as their own application I'm ensuring proper compartmentalization. This ensures that I'm not accidentally referring to code models/controllers/views/helpers that are not a part of the engine I'm developing.
If you're developing multiple engine type plugins this way, you might want to condense a few of the steps with a utility script. Such as one that streamlines the process of turning an application into an Engine plugin.
It should restructure your app as necessary and populate the files that plugins should have, such as init.rb.
You might want to give a look to Desert framework as well .