On 9/19/05, Peter Speltz <[EMAIL PROTECTED]> wrote: > On 9/18/05, Frank Carnovale > <[EMAIL PROTECTED]> wrote: > > David B. has done Maypole::FormBuilder and Peter S. has proposed > > "SuperModel"; I haven't studied these but it sounds like both are great > > work but with a lot of common ground.. can you guys let me know if these > > are complementary? > > They pretty much do the same jobs. FormBuilder is much more powerful > and complex too than AsForm. I wanted to dig into it some but I never > got the time and had AsForm working for me and the processing so I > have to finish up this app with what I have. I really like the > simplicity of AsForm and FromCGI and there will have to be pretty > compelling reasons to tear me from them. > > I'm not real sure if they are complimentary. More mutually exclusive > now i would say. My system is no different than vanilla Maypole. One > routine makes the form inputs, another processes them. I'm not really > sure how Daveś get processed but FB objects make the forms.
I agree, you've got to pick one and stick with it. Right now we're exploring the problem. I'd like to see code shared between Maypole, SuperModel and FB, but I think that's going to take some time, maybe Maypole 3 or even 4, until we understand the commonalities. That process will be helped when we figure out a system for plugging in code to the model. But even then, there's not much advantage to making them work to the same interface. I could see them both working to the same update_foo() or create_foo() top level interface, but as soon as you want to do anything else with them, with FromCGI/SuperModel you're looking at HTML::Element objects (big API), and with FormBuilder you're looking at CDBI::FormBuilder/CGI::Formbuilder objects (big, very different API). But as you say below, standardizing on the top level calls would be valuable. > I think we need to put some thought into the interface for the Model's > form building an processing. The 2nd rule of good software design > (or is it 1st?) : "Program to an interface, not an implementation". > It would be nice if people could use whatever implementation they > wanted to get the functionality they need and not have to change > anything but configurations. Ie , their models could go on calling > to_cgi , create_from_cgi , to_field, but these would act different > and use data they put in configuration. Like if I prefer to use FB > objects in templates rather than hashes of HTML Elements, the > interface should be the same that gets the object or hashes there and > they should get put into the same template variable (I think anyway) > and I hate to say it but that should probably be classmetadata.cgi. > Seems as good a place as any to me. > > (There issue with classmetadata was just about not making cgi for > every page right? Or was there more to it than that?) That was the main issue for me, and still is. But I've been working with TT lately and I can see why it was necessary - it's difficult to make a bunch of objects in the template, easier to supply them from outside. FormBuilder is different because you only need to make one object, generally from a very simple method call, so that's not an issue. There's also the scenario where you build several forms, from different classes, on the same page. You only get classmetadata for the class that happens to be in the url. So you still have to go off and create your cgi objects somehow anyway. d. HS^ľéXŹ˛'˛Ţuźjg˛˘ęÝz÷Ľ˘×!jY^ŹÂ+a ëzş'j ŚŽ÷Ť'×čúŢyŠÝm秾ęŢvÚ0v¸ÚZ˛fžň˘ęďzź¨Ât¨+f=#Â'$ ęŢśek(mś˙˛Ťqç莧zßŕzş'j)Ę%yׯzYX§XŹ´Ć˛Ś^uëŢXŹśË(şˇ ~ŕzwŰił˙ĺËl˛Ťqç莧zßĺËlţXŹś)ߣůĘ%yׯz
