I'm developing by Openui5 a portal. My portal have 2 apps. I I have organized the code in folders:
root
|
|____app1
|____app2
|
|____appN
In each app folder I have "master" folder, "detail" folder...etc..
What is the best way to organize the code?
Now I have an external structure of SplitView from which I call the sub-apps
(simply, when I select the app name from the list in the master column I replace the general master-detail pages - or the current app master-detail pages - with master-datail pages of the app selected)
Thi is the right way to develop a multi-app "portal"?
Definitely not the worst approach :)
You might also want to think about using UI5s Component concept. It allows for a better separation of apps by providing dedicated Router and EventBus for every component. It also isolates the sub-apps models from each other so that you can have models with same name in every component (handy for i18n/ResourceModel). A component does not even have to live within the same location.
The perfect match for what you plan to do but might be a little oversized though since placing different subviews (master/detail) from a component into the parent component can get a bit tricky.
GL
Chris
Related
or "How to decouple UI from business logic in Delphi?"
Each target platform has its own set of native firemonkey controls (Windows=VCL, MacOS=TMS mCL, Android=D.P.F, iOS=TMS iCL and D.P.F). The new FireUI (multi-device form designer) is a great solution for styled components, but not for native components because it still requires the same component on the master pane to support all platforms. As you cannot mix them on the same form, it completely breaks the whole idea with Delphi.
A lot of developers would say that Delphi is the broken approach, see "Why FireMonkey is so fundamentally wrong in every aspect". However, the premise for this question is NOT to argue against Delphi, but to get the best results out of what it does offer.
The conclusion is then that for each form in your application you have to make a separate form for each target platform. This leads to these questions:
Challenge 1: How to include different form files in your project depending on your target platform?
Solution 1: include all of them, i.e. MainForm_IOS.pas, MainForm_Android.pas, MainForm_Win, MainForm_OSX.pas, and then use compiler directives inside the files, so only the content of one of the files is active. Disadvantage: a large application can have many forms (we have around 40), so we are talking about a large number of included files.
Solution 2: Do not include them in the project, but instead just place them in seperate folders. Then you can add the matching folder to the search path for each target platform. Disadvantage: They will not show up in the Project Manager, so it will slow down the workflow every time you need to find a file.
Solution 3: Create a project for each target platform. Disadvantage: Every time you add new units or change common project settings you have to (remember to) apply it to all projects.
Update: As suggested in the Malcom Groves video, placing all the business logic in a package will remove the disadvantage from Solution 3. So I consider solution 3 as the best approach.
Challenge 2: How to connect the different device forms to the (same) business logic?
Possible solution: Create a "Helper" class that contains all the code you would normally have in the form unit.
Update: This "Helper class" is actually what the MVVM calls a ViewModel. What I need seem to be a MVVM framework that can support the databinding. I have made another question about that.
Any input and suggestions about best practice are welcome.
For challenge 1:
You can conditionally link in your FireMonkey form resources depending on the compile target:
{$R *.Windows.fmx MSWINDOWS}
{$R *.Macintosh.fmx _MACOS}
etc.
This is excatly what the XE7 Multiview designer does, but I see nothing against using this mechanism to link whole form files conditionally in to your executable. Of course you might also want to ifdef the corresponding units in your project file.
For challenge 2: Just use some form of Model View Controler logic. So your platform dependant forms will talk to a platform independant controler.
I'm trying to build a simple content management system based on the Zend Framework 2. The problem is that I don't know how should the folders structure be like.
Until now I have to solutions in mind:
A. Building a general "Admin" module that has multiple controllers like Login Controller, Pages Controller, Posts Controller, each of this controller with his own actions.
B. Building an module for each component, like: Pages Module that has an adminController an an frontendController.
I'm sure that none of the above solution is the corect one, but couldn't find any solid solution or books to provide one. I've taken a look at gotCMS but noticed that this one i.e, saves all the data like layout views in the database, and this is not a solution.
Though it's a very first alpha solution, I work on ensemble which is what I'd rather call a content management framework.
Ensemble's admin runs on ZfcAdmin. So you can drop in a Blog module which just has a admin controller under ZfcAdmin's route. But you can also manage pages (like texts) with a navigational page structure. All content parts (text, blog, etc) are separate modules.
So I'd suggest you take a look at the sample application and you can check out our blog as well, which just hooks in into ensemble. I know currently the documentation is scarce, but if we reach kinda beta stability we will focus more on docs.
The main benefits for "your system B" is you can drop in modules when needed. They all provide their own config, controllers, models and views. It's easy to install them from a developers perspective (load in composer, enable in application config) and you can easily override any view with your own ones.
TL;DR: choose structure B and have a look at Ensemble.
/edit: seeing you comment on Sam's answer: yes you have to do that. In ensemble, you specify a route config for the frontend and create your admin routes as child routes of ZfcAdmin. For both the frontend as the backend you have separate controllers.
There is no right or wrong when it comes to building something new. Personally I'd go with B. I wouldn't even name the Controllers like you did (I'd break them down a lot more, like NewsAddController, NewsEditController, NewsDetailsController, etc...). Then I'd have an AdminModule that would simply display a new Layout with a specific "AdminNavigation". This AdminNavigation can be filled via the other Modules (i.e. NewsModule would inject it's own administrative Routes into the AdminNavigation via module.config.php)
I was wondering if page templates can be built instead of individual components in Teamsite 7? I've seen other cMS systems where it is just a page template that has lots of functionality built I and you can "switch" on and off elements that you want to display instead of having to drag components onto a page? Is this possible?
Old question, but since I just came across it:
Yes, TeamSite supports templates (.template) files which can be partial or full page templates. The default location is iwadmin/main/livesite/template.
I recommend downloading the developer guides from Autonomy's web site for detailed information.
Templates in teamsite/livesite is like a bag that can contain components. But in order for a functionality to be developed in teamsite/livesite we need to create components. certainly we can avoid dragging and dropping components in each page by creating templates and dropping components within it for once. Keep in mind templates are bound to layouts. for each type of layout we need to create a template. Please have a look at TS_7.3_SiteDeveloper_rev1, Chapter 5.
Yes, you can create templates instead of dragging components.
Since, TeamSite supports templates (.template) files which can be partial or full page templates and resides at location : iwadmin/main/livesite/template.
So, whenever you try to create a new page everytime the HTML code required for that page gets automatically added with the template and layouts you selected.
But, again this is not good since you can have any number of templates you need but this could create confusions at times when you try to create a new page since you will need to remember every template name and contents that you will need for a particular page so it's better to have small lists of templates and layouts since then we can say that there is reusability in our application/website which we are going to develop using Teamsite and Livesite.
Please vote the solution if its helpful.
Thanks!
I am confused about how to make a multipage app in one GWT project. I have one page with my app and would like to provide an options page.
I don't think you can use 2 onModuleLoads() or something.
So how can you achieve a multipage app in 1 module?
Thanks
Take a look at the MVP architecture -
http://code.google.com/webtoolkit/articles/mvp-architecture.html
Even though you don't actually need an MVP paradigm to create a 'Multi-page' gwt application, you will be better off following it in creating your apps.
Basic idea is, you create different view-presenters that will act like different 'pages', and the app controller activates the correct one based on the logic you provide.
EDIT - you can even create multiple html-pages with their own onModuleLoad(), You should prefer that only if - there are logically 2 different applications or you are modifying an existing webpage and cant do without it. I believe you don't have those issues based on your question. Let me know if its otherwise.
what if i have ecommerce application?
like i have
1)sale page
2)list of product page(grid view and list view)
3)detail of product
4) zoom images for that product.
what kind of template should i use?
i refer this post but its not clear.
New iPhone App - How to Choose which Xcode Template to Use?
Thanks
If you have a hierarchy of views in which you go from general to specific information, then you want the navigation template.
However, most of the time, the templates are just starting points for learning. In most cases, you will have an app that is a combination so you start with the generic windows-based template and then flesh it out yourself.
If there is a similar application on the AppStore you may like to see how they have approached it, generally there is something similar that can help you clarify how you would like your application to function.
From the sounds of your application idea you would probably be best served by the Navigation template. But after all it is only a template, you can completely change the structure of the application later without needing to start another project.