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.
Related
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!
I am trying to follow the Wizard pattern in Forms sample provided with Play (https://github.com/playframework/Play20/blob/master/samples/java/forms/app/views/wizard/form1.scala.html).
This approach looks okay when the number of fields are static. But, how do I deal with this when the fields are dynamic. e.g. if there are going to be multiple profiles that a user can create in step2, how do I represent it on this page?
Also, does it mean that every page of my wizard will have to know about all the controls on rest of the pages, and make those hidden? There must be a better approach to solve this problem. Can you pls help?
I had similar problem while working with wizards. I solved it by decoupling my DB models from UI models. e.g. at DB level, I have one model that represents a whole car. At UI layer, I created multiple models that represent parts of the car e.g. wheels, seats, doors etc.
In the UI wizard, I use the UI models. So, at any given step my wizard step only needs to know about the parts that it operates on. I can apply the validation constraints such as #required etc. on these models. If form validation on part succeeds, I would update the DB model with that information. HTH.
I keep on finding myself wanting to add fields to CRM forms that don't actually represent physical fields on the entity. I want these fields to be sent in the Update message, for the benefit of my Plugins...
For example, imagine something like the out-of-the-box contact/address functionality. The main contact address is exposed as a set of fields on the Contact form. However, in actual fact there is some magic going on behind the scenes that causes an Address record to be created for the Contact containing the address details. I don't actually want to reproduce this, but it's a fair example...
Now, I know how to write a plugin that takes the address fields entered in the Create/Update message, and actually writes them into an Address object instead. That is simple enough. It seems the hard part is convincing CRM to display fields on the form for the user to enter the address data.
The only way I can see to do this is to create "fake" fields in the Contact-equivilent form, so that the form editor allows me to add the fields to the dialog. Then I have to filter these attributes out in a plugin, so the fake fields don't actually get written to the DB.
This would work, but involves filling the DB schema with fake columns that will (or should) never have any data in them. This makes future cusomisation of the system more confusing, as there are decoy fields called "DON'T USE - Address1" knocking around in all the GUIs. The problem gets worse when I need a fake Lookup field - this involves creating a fake relationship.
So: Is there a way to achieve the same thing without dumping fake garbage in the database schema?
Is there, perhaps, some way to create a form field for an arbitary attribute in Javascript on the form, such that the Attributes will be included in an Update message?
Sure, I realise I could IFrame or Silverlight something up to cater for this, but I'd rather use the genuine CRM form fields, and handle the data in the Update/Create message plugin hook.
Unfortunately, you have already mentioned the two options that I can think of: fake fields or custom IFrames.
I know it feels "dirty" but I actually haven't had much trouble doing the fake fields thing. Standardized naming conventions are your friend. I prefer fake fields over IFrames because users can still query and filter them in Advanced Find, reports, views, etc.
Just make sure they are readonly and make sure your plugins don't swallow exceptions - you want exceptions to bubble up and cancel the transaction instead of the possibility of the main record getting updated without the children.
As I have a complex domain model (DDD) where I need to create a few hundred forms in the user interface, I'm looking for a generator, preferably embedding the apple layout rules, and data binding. This is crucial to get a uniform application appearance.
I would prefer the generating to be of run-time instances (introspection), not static source code.
I do not want to build from a data model, as that doesn't have enough information to create something useable. I have information on grouping, validation, roles and rights, navigation, filtering, actions, workflow so I should be able to do much better layouts.
Even better would be the ability to also generate forms for the iPhone/iPad, using the default navigation.
[Results]
Sensible TableViews looks like the right kind of solution for iPhone. The descriptions are not yet sophisticated enough but provide a good starting point.
Interface Builder will do this for Core Data models if you option-drag parts of (or all of) your data model from the Data Modeler into a window or view in Interface Builder.
When you drop the managed object(s) you dragged, you're given an option to create a Single Item View, a Master/Detail View (with search and detail fields and add/remove buttons), or a Collection View (with box + search field).
I don't know of any third-party solutions to do this from "just any model." It'd be a great tool, but would likely require using an object model to define the entities (like Core Data's Managed Object Model).
Sensible Tableviews Might be able to help you. I haven't used them myself but it looks solid. It also supports generating forms from core data entities.
Maybe Echasoft Reports would work for your problem? (Plugin for Interface Builder that gives you easier reporting capabilities). I saw this demoed at NSConference, and it looks pretty awesome. Commercial, yes, but for 100+ forms it might be worth the money...
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