Let's say you have two GWT applications: the first (which is on another server as the second) has implemented some views that can be used to change the configuration separately.
The other one can manage (and access) some of the first ones and should configure them without forcing the user to login on every site.
It would be bad to just copy the code of the configuration, because this would duplicate code and we have to maintain it for every version, because the configuration-dialogues can change between versions.
Is it possible to include / load that view into your main GWT app, so that the users can use it the same way as your main application?
You can - Display the second app in an iframe. But if you use cookies beware of same origin policy if the domains are different for the two sites.
The other solution is import the code into the new one and let it perform independently here.
(A lot depends on underlying architecture of the two apps of course)
Related
I have several small utility apps for iOS. I want to combine these into one app with each utility accessed from a menu. I'm trying to figure out the best way to do this. The apps use Core Data which makes things slightly more complicated. Are there any standard ways of doing this or is just a matter of glueing pieces together until I get it to work?
Thanks
I recently worked on one such application. The design was as follows
-> Each sub application registers with the container app by providing the name of it's app delegate. I'd maintained a plist for this purpose which holds a mapping of the app name and the appDelegate class.
-> Whenever the user selects an app the container app will instantiate the app delegate and add the main view controller returned by it as the root view controller.
This design helps solve the logical part of the problem. You will still have a hard time before compiling all the source code as a single project.
As far as core data is concerned you must not have a hard time with it if each of your sub application uses a different object store.
I have built an app that does some computation and communication with varying internet resources. I branded my application with its tab bar navigation bar for three corporate clients, the only change was the difference in pictures and coloring. So I created three targets and handled target membership appropriately.
So far, so good. But what if I wanted to customize the whole layout of views or even the navigation of the app for a client? For example, the next client could ask for a navigation controller based interaction instead of a navigation based on a tab bar. Or to add one more label in one view. Or to use a pie chart instead of a bar graph to visualize a certain set of data.
It leads to very ugly code if you put all different targets in one project with all these if/else if/else if/else if/... blocks of code. What if I had 100 clients?
Now here is the question: In my imagination an ideal concept would be if I could make an Xcode project named "Base" that does all the domain specific computations, communications and so on (of course) and has a basic, non-branded UI. This way the code can be easily maintained for all clients in one central repository. Then, for every client, I create a whole new Xcode project, import or reference the "Base" project and when I click on Build without any customization, it already builds me the non-branded, but fully functional app. If a client requests to have a modified layout, I subclass the corresponding view. When hitting the Build button again, it should bring up the "Base" app but the certain subclassed view replaced the standard layout.
Can this idea of a "Base" app with "overriding" the visuals be done elegantly in Xcode?
I did exactly that for a client last year. I had one framework app that used a header shared with the app project. It's almost like a protocol in that the app "commits" to supplying some strings, views, and images. You can start with a fairly simple app project, and as you find you need more variation move code out of the framework into the app. The header was the implementation of a class-methods only class that vended the app specific data.
In my case we had 7 or so apps (all in the store now) yet not a single bit of knowledge in the framework of exactly what app was using it.
As an example in app did launch, the framework might query if a sound should be played and if so ask for that resource - same with images and other variations.
One way to do it would be to create a static library. You could stuff all the commonly used stuff into a static library and then reference it in the other projects.
Maybe most of the stuff lives in the static library and you just have one or two files in your app project. This would work well if there a very minimal amount of changes between applications (ie: just style changes like you mention in your post).
Another technique would be to use generated and template code. The idea would be that you have your boiler-plate code and you run a script that would set up your project and resources based on provided colors, logos, strings, etc.
In the end, you'll likely want to use a combination of the two approaches above based on your requirements.
I know this is similar to other topics, but I've not yet found a satisfactory answer.
I have a GWT / GAEJ application that essentially allows users to interact with the web app as if it were a desktop app. i.e. they login, and use the application in full-html mode (i.e. the GWT app occupies the entire html page). They are typically power users and so don't mind a few seconds dowload / login time when starting to use the app. Typically they might stay logged in for several hours.
I would also like to make available some small subsets of functionality, pointing to the same Back end, as widgets to be included in OTHER existing websites. I know one of the features of GWT is that you can either embed your GWT into existing html pages or go full page.
My question is how do I partition the GWT components into small tidy parcels so that only the relevant bits are downloaded for these embedded 'widgets' whist not having to duplicate my backend code. (for example I could create a new GWT project write only my small widget and copy the server side code - but I really don't want to do this!) Each widget still needs to interact with the same backend so none of them will be stand alone GWT. Communication is GWT-RPC.
anyone done this?
Seems like you want to split your GWT stuff into multiple GWT modules that you want to later combine in possibly more than one project. One way is having a multi-module maven setup (gwt-maven-plugin), there's no need to copy/paste code.
I'm developing a site in Symfony, and I'm not sure what the best way is to handle this scenario.
I'm creating a party bookings system. Anyone can go to my frontend app and submit a new booking. Once they're finished, they'll just get a confirmation screen, they can't edit it. Easy.
Only certain users will be able to get to the admin app (it might be secured simply by being on an intranet, but that's not important, just assume it will be only accessible by admin users). They'll be able to view the list of submitted bookings. Easy.
My problem is around code re-use when allowing admin users to edit existing bookings. When you do generate-module in Symfony, the generated module (which as a newbie I'm assuming is a good example of structuring things) creates the form as a partial. I've had to customize this form a lot for my usage (lots of Javascript, etc), so of course I want to re-use this code, to be able to load an existing booking into this form. But there doesn't seem to be a way to share this partial between the apps (I've seen people mention making a plugin...but this seems complicated for this use).
I considered using an IFrame to load the form from the frontend and just passing an "id" parameter to load it in edit mode, but this would mean that the edit mode is not secure - anyone could go to the form on the frontend and pass this parameter to edit a booking.
I also considered putting all of the form display code (HTML, Javascript, etc) in a method on the form object, but this doesn't seem very MVC - all of the display code is then in the form. But this is only because I'm thinking of the form in the same way as a model - is that right?
I feel like this should be a common situation. You can share models and forms between apps, why can't you share this common form display code too?
Thanks!
You should reconsider having 2 applications in the first place. Not only you run into the code reuse problem, but also i18n, testings and other issues. I find it much easier to have 1 application with different bunch of modules for frontend and backend users. You can configure security per module. You can have one sign in form for all users and redirect them to appropriate module based on their credentials.
You can reuse partials between modules inside the same application, but you seem to be talking about two different applications (frontend and backend) so as far as i know the only way is to copy & paste the partial from one application to the other...
Iam coding a dating application for facebook. The application has to have a standalone web application part and a Iframe based part which runs inside facebook canvas.
I want to know good ways to design the application. Iam using zend framework, so here is my idea.
One approach that am planning to use is this -
The application folder to contain 2 controllers, index controller being the entry point of the standalone web application and another controller- FacebookController to be the entry point of the Iframe being run inside facebook canvas. Both of them calling the same view files which get written based on which controller is writing to them.
The second approach is to have one single controller as the entry point and use 2 layout files. One for the standalone web application and one for the facebook canvas app.
The reason for choosing these approaches in that the authentication mechanism of the two applications is different.
To get an idea, have a look at www.areyouinterested.com, Iam planning to do something similar to what they have done.
Please suggest me what would be the best way to go around this.
Your first choice is best.
Two Controllers. Two layouts. Common views.
This gives you flexibility to change around a lot of one or the other without breaking the opposite one.
If you feel ambitions, I would even go with two modules. If your application is structured well enough each module will have common components that are re-usable.