There's several workflow plugins in the plugin repo that may be worth investigating (pageflow, especially)
I know there's a pretty complex one based around the eZ Workflow component - I looked at that a while back with a view to creating a plugin along the lines of Spring WebFlow... On 13 Apr 2010, at 15:59, AJStoneham wrote: > Is the standard way to go through a mult-step work-flow? I would like > to know too. > > I don't think you will have a problem with your approach. I think back > in the day I had problems serializing forms because some widgets had > an unrealizable database/pdo handle bound to them, but I think its a > non issue now. You can try persisting a form in the parameter holder, > but if it does not work, just persist a plain old php object acting as > a data-structure. The common pattern I see: > i- Have one state-full class and carry that through the lifetime of > the work-flow. Held in the Parameter holder of course. Perhaps you may > want a collection of little state-full classes, then in that case, > namespace them to the name of the workflow and flush out the namespace > when your done/last step. > > ii- Author multiple small form objects for > a) easy construction of the workflow UI, > b) the form API advantages, (data-structures on form > submission, validation, ) > You don't necessarily need forms built of your entity objects or need > to 'mutate' (as opposed to evolve ;-) ) the autogenerated forms to > your needs. try making standalone forms with widget and validation > schemas and work with those. It helps when the same entity's fields > are on different pages of the workflow, or your representing key > fields only from a package/family of entities. > > iii-Author 'thin' Action/Controller code that will > a) inject forms and pull from (call validate and re-inject if > needed) the form if submitted > b) mediate between the form data-structures and the statefull > class in (i) > c) interface with the business model tier as your workflow > requires. > I say thin as thin controllers are good practice, from my research and > experience, pushing queries into the model tier, (unless its a simple > find) and pushing complex tasks into an appropriate/new if needed > model class means you get more code re-use/DRY factor, as we can reuse > decoupled OO business model objects, but not so in controllers. > > With best regards, > Alex Stoneham > > On Apr 13, 5:03 am, Juampy72 <juamp...@gmail.com> wrote: >> Hi all, >> >> I need to split a form it in various steps. >> >> So far, I have created a single Form class with all the fields but, >> how could I implement in in consecutive pages? I was thinking about >> saving form data from step 1 to step 2 in the session, but I may have >> problems with form serialisation. >> >> Any ideas? Is there a standard way of doing it? >> >> Thanks > > -- > If you want to report a vulnerability issue on symfony, please send it to > security at symfony-project.com > > You received this message because you are subscribed to the Google > Groups "symfony users" group. > To post to this group, send email to symfony-users@googlegroups.com > To unsubscribe from this group, send email to > symfony-users+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/symfony-users?hl=en -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en
