We're getting started on a new application that will run on several platforms (web, mobile, tablets etc). The goal is keep the models and controllers the same for all the platforms. Only the views will be changing. For example, if I have Roles view (and RolesCtrl) and Persons view (and PersonCtrl) on different pages (roles view redirects to persons page with role id as query string or something) on one platform, these two views might be combined into a single page (role id should not transfer to person page but to another view on the same page) on a different platform. I understand I can have separate divs and keeping the controllers intact, but since the UI flow is different for different platforms, how can that be handled? Is it feasible to keep the controllers unchanged?
Is this the right approach? Any help is greatly appreciated.
I would suggest proving this out by creating a small project to implement some piece of functionality backed by a service that AngularJS will communicate with.
It sounds like you might have some behind the scenes complications here. I would suggest that if you do use AngularJS to make sure all of the developers are making their HTTP communications done through AngularJS and not try to go work around it.
From my short experience with AngularJS I think it would work fine and may actually make things simpler because of it's easy single application model.
Related
I have recently gone thru several articles on AngularJS. As AngularJS maintains controllers and models separately from view. As soon as model gets updated it updates View automatically and vice versa as it is two way binding. But as much I have gone thru all the articles I have found that all views, models and controllers are managed on client side.
Do we have any way to put controllers and models on different machines than client side ?
Yes, but not automatically. AngularJS is a client-side MV* framework. There are also server-side frameworks and even some combos like Meteor that run on both sides. But always there is some messaging back and forth, and at the end of the day, what is it you wish to do on the server? Servers and clients are almost always very different, and where a client might be drawing forms and tables, a server might be reading/writing database queries or managing multimedia assets. That means there's rarely a benefit to a 1:1 duplication of functionality in both environments.
I would suggest you evaluate the excellent ExpressJS framework for NodeJS. This is a great building block for server-side MV* apps, especially when combined with a good templating library like Swig. You can easily create a CRUD API here (in just a few minutes) that manages creating/updating data objects in a model and storing them in a database like MySQL, Mongo, or something like Redis. Then, back in AngularJS, you can use $resource, Restangular, or similar to map between the two.
This technique has a few more steps in it than Meteor would, but it gives you an incredible amount of flexibility and doesn't take very much code to produce.
I'm still sort of new to CakePHP, and I've presently created and deployed one (rather complex) application using it. It has full user and group support and I took the time to get the access tables working and everything.
Now, I'm creating a separate application. I initially just created a brand new CakePHP installation, but I later realized that I wanted to authenticate users based on my first app. They currently use different data sources. I understand that there are a couple of ways this could be accomplished, with various pros and cons. Do I:
Keep them separate, add a data source to my extension application, and port my user authentication code over?
Keep them separate, process logins with the first application, and somehow share that data with the second using a communication protocol?
Combine them into a single data source and accept the added complexity in my app?
Something entirely different?
I'm using CakePHP to create both sites, which will be running on the same host/hostname, and connecting to the same MySQL server. Users are always stored/created on the main application, and just need to be passively accessed by the second app.
Honestly it sounds to me like you could bring them together with ease. Your reasons for keeping them separate sound to me like you could just keep them separate pieces of the one program.
For example the application I work on for a living does many of these things. Users can register, they also have access to a calendar of events, job postings, recent news, and about 25 other modules. They are just different parts of the program.
You could have one application that has a route like /users/register which the users controller takes care of registration. Then you can have another part of your application that routes to /calendar/.... where the calendar controller will take care of the calendar logic. If you need separate calendars for students and faculty you could have routes like /faculty/calendar/1 and /student/calendar/1 which would route to different parts of your calendar controller.
It's all about modularising your application, so that you can easily maintain code that is logically grouped together. You don't have to separate them so much so that they are two different applications.
I think you will avoid many headaches in the long run.
If it makes you feel better about my opinion the software I work on that I was talking about is an enterprise solution that deals with (literally) millions of documents per day, and hundreds of thousands of users per week on the government level.
I am writing an application, there are various forms and their corresponding datamodules.
I wrote in a way that they are using each other by mentioning in uses class(one in implementation and another in interface to avoid cross reference)
Is this approach is wrong? why or why not i should use in this way?
I have to agree with Ldsandon, IMHO it's way better to have more than one datamodule in your project. If you look at it as a Model - View - Controller thingie, your DB is the model, your forms would be the Views and your datamodules would be the controllers.
Personally I always have AT LEAST 2 datamodules in my project. One datamodule is used to share Actions, ImageLists, DBConnection, ... and other stuff throughout the project. Most of the time this is my main datamodule.
From there on I create a new datamodule for each 'Entity' in my application. For example If my application needs to proces or display orders, cursomters and products, then I will have a Datamodule for each and everyone of those.
This way I can clearly separate functionality and easily reuse bits and pieces without having to pull in everything. If I need something related to Customers, I simple use the Customers Datamodule and just that.
Regards,
Stefaan
It is ok, especially if you're going to create more than one instance of the same form each using a different instance of the related datamodule.
Just be aware of a little issue in the VCL design: if you create two instances of the same form and their datamodules, both forms will point to the same datamodule (due the way the VLC resolves links) unless you use a little trick when creating the datamodule instance:
if FDataModule = nil then
begin
FDataModule := TMyDataModule.Create(Self);
FDataModule.Name := ''; // That will avoid pointing to the same datamodule
end;
A data module just for your table objects, if you only have a db few tables, would be a good one to be the first one.
And a data module just for your actions is another.
A data module just for image lists, is another good third data module. This data module only contains image lists, and then your forms that need access to image lists can use them all from this shared location.
If you have 200 table objects, maybe more than one data module just for db tables. Imagine an application that has 20 tables to do with invoicing, and another 20 tables to do with HR. I would think an InvoicingDataModule, and HRDataModule would be nice to be separate if the tables inside them, and the code that works against them, doesn't need to know anything about each other, or even when one module has a "uses" dependency in one direction, but that relationship is not circular. Even then, finer grained data module modularity can be beneficial.
Beyond the looking glass. I always use Forms instead of DataModules. I know it's not common ground.
I always use Forms instead of DataModules. I call them DataMovules.
I use one such DataMovule per each group of tables logically related.
I use Forms instead of DataModules because both DataModules and Forms are component containers and both can effectively be used as containers for data related components.
During development:
My application is easier to develop. Forms give you the opportunity to view the data components, making easy to develop those components.
My application is easier to debug, as you may put some viewer components right away so you may actually see the data. I usually create a tab rack, with one page per table, and one datagrid on every page for browsing the data on the table.
My application is easier to test, as you may eventually manipulate the data, for example experimenting with extreme values for stress testing.
After development:
I do turn form invisible. Practically making it a DataModule, I enjoy the very same container features than a datamodule has.
But with a bonus. The Form is still there, so I may eventually can turn it visible for problem determination. I use the About Box for this.
And no, I have not experienced any noticeable penalty in application size or performance.
I don't try to break the MVC paradigm. I try to adhere to it instead. I don't mix the Forms that constitute my View with the DataMovules that constitute my Controllers. I don't consider them part of my View. They will never be used as the User Interface of my application. DataMovules just happen to be Forms. They are just convenient engineering artifacts.
I am going to be creating a work order system with three roles
The "client" - The client can request projects to be completed by the worker. The project must be selected from a list of templates and various sub options all referred to as a campaign (campaign types come and go throughout the year)
The worker - The worker must be able to view work orders and mark them as accepted/rejected, work in progress and completed.
The overlord - He/She needs to see stats concerning the activity of the other two types of users.
So.
This is a web app. But a very simple one in terms of logic. Could something like drupal handle this? Or would I have to write my own modules? The other out of the box aspects of drupal make it attractive (admin, user creation, news feeds, etc...)
I have looked at Views and Webforms. Views seems great for querying and displaying data from the work order database (great for a portion of all three roles), but I am not clear as to how I interface with my work order database when creating and modifying work orders.
Webforms doesn't see to be the answer, I am sure I just missing something right under my nose.
Any hints in which direction to look would be great!
Thanks.
If you use a simpler, less powerful CMS, you may save time with the learning curve but lose time struggling with a less flexible framework. Also: Check how active the developer community is when evaluating Open Source software. You'll need support.
Views and Webforms may be tools that you'll end up using but what you're really talking about is work flow. You could build your own work flow with a combination CCK and views, yes. There are also work flow modules.
Are you and IRC user? See: http://drupal.org/irc
I am pretty certain that you can do this with drupal. I would suggest looking into using an easier CMS than drupal for something simple like this. Using something like MediaWiki for this application might be quicker to develop and have less of a learning curve. If you don't mind putting in the time to learn drupal, I think you will ultimately have more freedom.
First of all, don't underestimate Drupal's learning curve. Especially if your PHP and/or programming skills are relatively new. Drupal does a lot of things in it's own way, and it's good to know that way.
Secondly, Drupal is (imho) made first of all for outward facing sites, it can have a lot of stuff just for the users and not for the public, but a lot of its functionality is made for the CMS part of the system. You might consider using a more framework-style system like Zend Framework, which components are a bit more "loose" but also offers less functionality out of the box.
Thirdly, depending on what a work order is and how it should be treated a custom module could be needed. If a workorder has a really simple datamodel, it could probably be done without programming, but if it is complex you'll have to fire up your favorite editor. Don't worry, making a module sounds scarier than it really is.
I don't know how good your knowledge of drupal is, but to me this has CCK and Views2 and user roles written all over it.
Basically, use CCK to create your content types (remember the user reference field might come in handy to assign a node/record to a particular user)
Then create views for each user group (they could be shared, as you can assign them to more than one role type)
Creating a view where you filter the cck user reference field by the user looking at the screen may also come in handy here.
OKAY, there might be a little bit more to it than that, but what you want is doable.
UPDATE: To protect your site from unwanted eyes, check out the site security module as it puts a security wrapper around all of your website.
Views - Create lists - allow access by user roles
CCK - Define your own content types (add your own fields)
I am currently working within a custom framework that uses the database to setup a Page Object which contains the information about Module, View, Controller, etc which is used by a Front Controller to handle routing and the like within an MVC (obviously) pattern.
The original reason for handling the pages within the database was because we needed to be able to create new landing pages on the fly from within a admin interface and because we also needed to create onLoad and onUnload events to which other dynamic objects could be attached.
However, after reading this post yesterday, it made me wonder if we shouldn't move this handling out of the database and make it all file structure and code driven like other frameworks so that pages can be tested without having the database be a component.
I am currently looking at whether to scrap the custom framework and go with one of the standard frameworks and extend it (which is what's most likely right now), but I'm wondering whether to extend the framework to handle page requests through database like we are now or if we should simply go with whatever routing / handling mechanism comes with the framework?
Usually I'm pretty lenient on what I will allow to go on in a "toy" application, but I think there are some bad habits that should be avoided no matter what. Databases are powerful tools, with reasonably powerful languages via stored procedures for doing whatever you need to have done... but they really should be used for storing and scaling access to data, and enforcing your low level data consistency rules.
Putting business logic in the data layer was common years ago, but separation of concerns really does help with the maintainability of an application over its lifespan.
Note that there is nothing wrong with using a database to store page templates instead of the file system. The line between the two will blur even further in the future and I have one system that all of the templates are in the database because of problems with the low budget hosting and how dynamically generated content need to be saved. As long as your framework can pull out a template as easily from a file or a field and process them, it isn't going to matter much either way.
On the other hand, the post from yesterday was about generating the UI layer elements directly from the database (at least, that's how I read it) and not an unusual storage location for templates. That is a deep concern for the reasons mentioned... the database becomes locked to web apps, and only web apps.
And on the third hand, never take other people's advice too much to heart if you have a system that works well and is easy to extend. Every use-case is slightly different. If your maintainability isn't suffering and it serves the business need, it is good enough.