On Sat, Apr 11, 2009 at 6:31 AM, Gauthier Segay <[email protected]>wrote:
> > Thanks for your answer, please find some precisions bellow: > > On Apr 10, 4:06 pm, Jonathon Rossi <[email protected]> wrote: > > You could store the view templates/forms in your DB to make the workflow > of > > approving forms easier. > > The project already have straight deadline, it will serve as the basis > for future applications (I'm working out what part of the db model > will be part of the framework as well as object mapping and services). > > The DB storage of view templates idea was cited, in case it is > choosed, my main concern is to streamline the development (0 impact > for developer which should develop normal templates on filesystem) and > put this burden as a packaging / deployment concern. You could always have 2 template providers to allow developers to work on the file system, or just make something that overwrites the most current template revisions in the DB when you make a request just for development. The main reason I suggested storing them in the DB is that they are closely tied to the data you are storing for them which I assume you would want to use the same template version to edit the data stored for the forms later on. That brings up the point that you need to migrate data from one revision of a form to another, or isn't this an issue because the data will only be displayed using the revision it was created with? > I depends on the people creating the forms and the complexity of the > forms, > > but I wouldn't have expected that forms would be created as view > templates > > because this isn't a very simple task for general computer users. Unless > the > > person creating the form is using Visual Studio, then a stongly-typed > > property page isn't going to give much. > > The assumed choice is to have developers managing change requests > which will have an impact on forms/data presentation/validation. So are you storing a list of fields and the validation to be performed in your DB which will be linked to the template source? For example, revision 1 will have this set of fields with these names which match the names in the template, and revision 2 has this different set of fields with a different template. custom form generator as well as middleware such as infopath or > sharepoint have been ruled out because there is not enough time to > integrate such things before we deliver the first application and the > soundess of theses approach is unsure at the moment and there is a lot > to manage with existing environment (workflow engine, multiple web > services...) Fair enough, those systems can become very complex. > > Can to elaborate on the type of user creating the forms and how often > these > > forms will be changed. Can you also clarify something about the system, > are > > the forms used to upload documents or are the forms the actual documents. > > Change request may appear as small batches on a month/trimester basis > a little while after the initial deployment > > > I'm not sure what your comment about child containers is referring to. > > I thought about server side sanity/rules validation services which may > have the same interface and being registered in a child container for > specific versions, it was a rough idea and I may find simplier > solutions. So are you deploying more code when you change the templates, and not just configuration in the DB? > Thanks again for your feedback > > > On Thu, Apr 9, 2009 at 9:55 AM, Gauthier Segay <[email protected] > >wrote: > > > > > > > I'm designing an application that will manage document approval > > > lifecycle, it's very likely that MonoRail would be choosen as the web > > > stack. > > > > > I need to plan about versionning issues of document input and approval > > > forms, theses forms will be available as read only for completed > > > documents and the application will have some changes in the future > > > about which and how data is displayed on theses forms according to a > > > revision number for the document/workflow instances. > > > > > I really want to rely on simple view templates and not mess with some > > > kind of generative meta model. > > > > > My basic idea is to have dynamic resolution of templates location > > > according to the document being displayed (it will have some workflow > > > revision number to lookup, could be used to map over the directory > > > structure of view templates), does it seems a crazy idea? > > > > > Also, I'm pretty fond of strong typed views (likely aspview will be > > > used), is there any pitfall going with "strong typed" property bag > > > population with this kind of scenario? > > > > > Finally I'm also sorting out this issue at the DB and service layer (I > > > think MicroKernel child containers will be of help here) so any > > > experience / feedback is welcome. > > > > > Thanks > > > > -- > > Jono > > > -- Jono --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en -~----------~----~----~----~------~----~------~--~---
