Hi Jason. Have you given any more thought to how components would work with WW? Currently I use the Include tag to build my page up from smaller parts. This is quite limiting though. It would be great if components could interact with each other. ie A date picker could add some JavaScript the header and maybe interact with other date pickers (ie when from date is increased, to date can be increased automatically). Or a form field could add some JS code to the form validation function that determines whether the page can be submitted or not.
----- Original Message ----- From: "Jason Carreira" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, September 22, 2003 3:23 PM Subject: RE: [OS-webwork] Thought concerning HTML form rendering Well, I would hate to have custom object types for this.... Tying apps to WebWork is opposed to the general WebWork idea. I see where you're coming from, but I'm not sure (without the custom types) how you can specify text vs. textarea... Also, how do you specify a radio-button set with enumerated values vs. a text box. I'm all for custom components, though, and I think adding things like a pre-built date-picker, etc. would be very valuable. Jason > -----Original Message----- > From: Joseph Ottinger [mailto:[EMAIL PROTECTED] > Sent: Monday, September 22, 2003 8:26 AM > To: [EMAIL PROTECTED] > Subject: [OS-webwork] Thought concerning HTML form rendering > > > Would it be better to have something like this: > > <ww:field name="foo.bar" label="'Bar'" /> > > instead of > > <ww:text name="foo.bar" label="'Bar'" /> > > Consider: the rendering engine can see that the field is a > String, so it can generally figure out the rendering type. > Maybe String isn't a brilliant idea - maybe there's a > possibility of creating new types in WebWork such that the > form can look at the type and say "Gee, this is supposed to > be a textarea, let's render it that way," or "Gee, this is a > numeric type, integral, let's generate an input field that > doesn't allow non-numerics or decimal points," etc. > > No, I don't have any code to show off for this, nor am I > convinced this is a "solution," and in fact, I'm not even > sure there's a problem... just trying to think in terms of > how a user might use this, without having to know the > destination types. Imagine: a Phone type, or a ZIP, or a > State... all with custom renderers that don't require > anything special on the front end... just a reference to the > field in question. > > ------------------------------------------------------------------- > Joseph B. Ottinger http://enigmastation.com > IT Consultant [EMAIL PROTECTED] > J2EE Editor - Java Developer's Journal [EMAIL PROTECTED] > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
