I'm planning out a web application using Laravel for the server side structure. The main goal of the application is to display a form that will allow the user to enter in Parent/Guardian and related Student information. The additional goals will be to allow administrators to log in and look up Parent/Guardian and Student data that has been submitted.
At the simplest, I feel like I could do this by using one controller for "Form" that facilitates the display of the form, the submission of the form data, and the showing of the stored data.
Thinking forward though, it seems like it would be beneficial to have the logic for the Parent/Guardians and the Students in separate resourceful controllers to make it easier/clearer to access and work with the logic per entity. If I did it this way though, it seems like I would need a third controller for the Form that would then call out to methods in the Parent/Guardian and Student controllers separately.
What would be the best way of approaching this structure? I want to go for the "pass the salt" or "just program what you need now" approach, but I know that I'll need more refined access to Parent/Guardians and Student data in the near future. My goal is to minimize the amount of refactoring by planning well at the beginning.
Any suggestions or insight would be appreciated.
Thanks!
Related
The backend developer has designed the RESTful API in such a way that when going into a section of the site I call one large request for all the data in all the sub sections. These sub sections data can be modified and saved. If that happens I would need to create a new model based on the model from the large request, populate it, and save it to a different service (PUT). This service can only PUT and not GET. I would probably create this model as soon as the user navigated to this section, and display the view based on this new model. Now if i navigated to another sub section, that large request model would be out of date and I'd have to fetch it from the backend again instead of making a smaller request for that section.
I propose to him to just create separate services for each sub section that i can easily fetch and save to (I'm using Backbone). Otherwise I'm creating sub models off a main model and they are dependent on each other and I'd have to write the code to wire them together instead of leveraging the power of the built in methods on the model like save, sync, fetch.
Does this not also create an issue in creating modular components if models are depending on other models?
Has anyone seen it done this way?
I'm in a similar situation. Our API was designed under the philosophy that a single request should give everything needed to render a page. So there's one major API endpoint that returns a main data type, and all nested objects are returned in a partial state. So if I'm requesting "employees", the API won't give a "department id" it will return a partial department object like:
department: { "id": "1", "name": "Department A }
There are great benefits to this approach! Making multiple requests is expensive, and you don't want dozens of API hits for every page load. The problem you'll find is that Backbone was designed for one to one mappings between models and API endpoints. They don't give you anything like a Data Access Layer, if they did both our problems may be solved.
My team generally would make "department" an attribute for the Employee model. This has a big problem. The way that Backbone Models register changedAttributes doesn't play nice with complex objects in attributes, which complicates forms based on data structured this way. It's somewhat frowned upon by Backbone developers too. The general consensus is to store complex objects in a property of the Model class, rather than an attribute.
In any event your parse and toJSON methods will get a lot more complicated than what you'll typically find in examples.
I would recommend you to use BreezeJS, which is built only for data rich application. Check out this link
http://www.codeproject.com/Articles/730450/Creating-Single-Page-Application-using-Hot-Towel-T
I'm working upon a small-scale enterprise database application. It works with such business objects as Vendors, Device types, Devices, Suppliers, Invoices, Departments, Employees etc., so I need to let users view and edit data from all these tables.
My first approach was to create a pair of forms for each type of business object:
a table to view and select an object
an editing form for this type of object
But now I find it hard to maintain all these forms, because e.g. if I want to change the look of all view forms, of course I have to edit each one of them.
So I want to replace all my view forms with a single one "template" form and to call it with some kind of parameters. The problem is, I don't know the right approach to perform it. Maybe there could be some example in some book or somewhere else?
I think the best way is by using Visual Form Inheritance .
Actually we use this kind of programming a lot, it keeps maintenance pretty simple. Stick your base functionality in the parent form, and specific behaviour in the child forms.
I have an edit page which is grows with the size of the app. We're now running in to a situation where the server side action (MVC) is handling image uploads and conversions alongside regular text saving to database.
What's the best way to make this more maintainable? Separate controller for images uploads, so that we create an writeable API? Or more actions within the same controller?
There are few ways, which could let you mitigate the problem with rising complexity :
Implement HMVC, where each controller calls sub-controllers. This would let you to split up the "update" tasks in logical and manageable chunks. Especially, if i am correct in thinking that there is more the one "update page". The HMVC structure would let you to assemble different update pages from existing fragments with quite minor additional hustle. Main disadvantage: relatively large change in architecture.
Split the update page(s) in smaller forms, each submitting to a different controllers action (or maybe a different controller altogether). Main disadvantage: user can update only one part at the time
Evolve the model layer, so that the API you use interacts with service layer instead of domain model layer. This will let you isolate the complexity of updated and provide a simpler interface to use in controller. This too would have the added benefit of composing update form(s) from manageable pieces. But i don't know the penalties that come with this approach .. never have used it myself.
The bottom line is: you will have to change one part of MVC. In your situation i would choose the HMVC way, but mostly because i am familiar with it, and multiform page might induce rage from users.
I have a situation with my MVC2 app where I have multiple pages that need to submit different information, but all need to end up at the same page. In my old Web Forms app, I'd have just accomplished this in my btnSave_Click delegate with a Redirect.
There are three different types of products, each of which need to be saved to the cart in a completely different manner from their completely different product pages. I'm not going to get into why or how they're different, just suffice to say, they're totally different. After they're saved to the cart, I need to "redirect" to the Checkout view. But it should be noted, that you can also just browse straight to the Checkout view without having to submit any products to add to the cart.
Here's a diagram of what I'm trying to accomplish, and how I think I need to handle it:
Is this correct? It seems like a common scenario, but I haven't seen any examples of how I should handle this.
Thank you all in advance.
Yes, this is certainly one way to handle it. If your widgets, whatzits, and whozits views are really that different, than it's probably not worth it to try any sort of inheritance scheme or smart view that is capable of displaying any of them depending on what's passed in as the view model.
If you're asking for how to handle the redirect, you should probably use RedirectToAction("Action", "Checkout") when handling the save actions on your widget, whatzit, and whozit controllers.
It would be good if you had a base Model class for each of these XYZIt items and could pass them as a collection of CheckOutItems to the checkout controller directly instead of having these intermediate controllers in there. Not really sure why you need to have these extra controllers.
You can use RedirectToAction
I have Lotus Notes application, deployed only as modifications (new forms, views, and adding a button to one of the "standard" views) in the main mail template (R7).
All these "new" forms and views are inherited in turn from my main application template.
Now, for one of these forms to function properly, it have to have a field, which is different from customer (not end user, but organization) to customer.
I do not want to break the inheritance from our template, so we can update the application easily by just sending a new template. So, I can't ask the client admin just to break the inheritance for this particular form, as it will stop all updates (or they have to be done manually).
So, let's say I have MainAppForm, which has a calculated field ClientCustomData. I'd like to have another form, which only has only one "default" field ClientCustomData. I can break the inheritance for this second form, as it has no really design elements which may change, and then the client can modify this default value to whatever they need w/o fearing that it'll be overwritten.
The question is - how from MainAppForm I can read the value from the other form?
Or - is there a way to store 2 data elements only in a mail template (I dunno, shared file, or something), so it becomes available to each user, and MainAppForm can get them, w/o a need to remove the inheritance dependency of MainAppForm from our template.
I can envision even a class library with just to functions to return this (I don't know why this approach smells to me).
Any best practices or advices?
I'm not sure if I have understood your querstion correctly, but it sounds like you want to have a small part of a larger form configurable per client. If this is the case, I think computed subforms could do the trick.
Consider the following scenario: Your application ships with the subform ClientCustomData that contains just sensible defaults for the client settings. The form MainAppForm includes this as a computed subform. It is then possible for the local admin to disable inheritance on the subform and changing the custom data without affecting inheritance on MainAppForm.
The obvious drawback is that you cannot update the ClientCustomData subform automatically once inheritance is disabled; Keep this subform as small as possible. If you find that you need more client-custom values, you can always add another subform in the same manner.
First a clarification: In Lotus Notes, you don't have forms reading from other forms. Forms are just UI objects. However, you do have back-end and front-end documents that get created with the help of Forms.
When you create a new document based on a form (for instance, a new email), you are creating a front-end document that hasn't been saved yet. That document can access other parts of itself or it can access any back-end document that has been saved.
If I'm following you correctly, you need some bit of data that is different per client/customer to be brought into documents based on MainAppForm. There are a few ways to do that. My suggestion is to use Database Profiles, which are special documents that can easily be accessed from anywhere in your database via Notes Formula language or LotusScript. Granted, you can't push data within those documents out via a template, but if you use a database profile to store your database settings your client admin can set options once and they won't get altered when the template changes.
Have a look at the #SetProfileField and #GetProfileField functions.
To answer my own question (still I do not know if I'm right in terms of Notes way of thinking, but looks promising):
I found the "Shared fields". So, I create 2 such a fields with a computed values (the ones I want to pass on), and make my MainAppForm use them. Upon installation, the admin will change the values and mark them to not refresh with the template.
I'd respect any pros and cons, provided from a Notes expert.
Thanks