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. > 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. 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...) > 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. 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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
