Hi Mike, > However, one component has three levels of > add/modify/delete plus several search/browse modes, so I don't think I > can get by without at least 20 actions.
Not sure if this is relevant to you or not but the above sounds a bit complicated so I thought I'd document here a solution I use because it might be useful for someone. Rather than using one controller to model 3 levels of add/modify/delete (by which I assume you might mean something like three entities, each related by a one to many mapping) I model just one one->many mapping and use it three times in three controllers. Say I have a study, studies have people and studypeople have addresses. I'd create three controllers: study studyperson studypersonaddress (not study, person, and address incidentally because the last two might be something different). All three would then have identical controller code apart from two areas: * The variable names of each entity are different (and so therefore is the code for loading and saving them) * More routing arguments get passed to each of the functions which handle the workflow depending on the depth. Other than that everything else is the same, you use the same workflow etc. Here are some URLs: Study: example.com/study/5 StudyPerson: example.com/study/5/person/3 StudyPersonAddress: example.com/study/5/person/3/address/1 You then just need to setup your routes so that anything to with address at the end goes to the studypersonaddress controller with extra routing args (study_id and studyperson_id) and then those extra routing args are passed to any code which generates URLs or saves the data. In that way the studypersonaddress controller itself pays no attention to what studyperson it is related to or any attention to what study that studyperson is related to since all that information is stored automatically in the URL throughout the process thanks to routes. This all means the URLs are really clean, the workflow is nicely encapsulated and the solution scales to any level of one to many mappings without any changes because the state is saved in the URL, each new depth just picks up an extra routing argument from the ID of the object it is related to. Hope that's useful, James --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" 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/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
