David,
What do you think of something like <include location="component://....ftl"> in the form widget, so that a block of FTL/HTML can be included right into the form. I think this would help with: 1. Allowing a mix of complex HTML and form widget stuff to be rendered together. Right now, you have to choose between the control of HTML/FTL or the ease of form-widget. 2. Allow repetitive things, like address entry stuff, to be reused across forms. 3. Allow for certain unique elements, like the stuff Alexandre Gomes was talking about, to be supported without adding all sorts of new tags to support them. Si _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
My initial reaction, as you might guess, is that I really don't like it. It breaks the semantics of the form widget and could potentially cause all sorts of problems in application. For now it is possible, and probably generally better, to just use the attributes to not include the form opening and/or closing and then from the screen widget include multiple forms interleaved as desired with FTL files. If you really need control over exactly how things look and you need to insert special things here and there, using an FTL file for the whole thing is probably much better, and probably even easier in many cases. It's harder, but not that hard... -David On Jan 13, 2006, at 9:46 AM, Si Chen wrote: > David, > > What do you think of something like > <include location="component://....ftl"> > in the form widget, so that a block of FTL/HTML can be included right > into the form. > > I think this would help with: > 1. Allowing a mix of complex HTML and form widget stuff to be > rendered > together. Right now, you have to choose between the control of > HTML/FTL > or the ease of form-widget. > 2. Allow repetitive things, like address entry stuff, to be reused > across forms. > 3. Allow for certain unique elements, like the stuff Alexandre Gomes > was talking about, to be supported without adding all sorts of new > tags > to support them. > > Si > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev smime.p7s (3K) Download Attachment |
Actually, I thought you might like it. :) (Especially after I saw the
bsh call inside the description="") But I think you have a good point. For really complex things it is better to work form into FTL, rather than vice-versa. Thanks, Si David E. Jones wrote: > > My initial reaction, as you might guess, is that I really don't like > it. It breaks the semantics of the form widget and could potentially > cause all sorts of problems in application. > > For now it is possible, and probably generally better, to just use > the attributes to not include the form opening and/or closing and > then from the screen widget include multiple forms interleaved as > desired with FTL files. If you really need control over exactly how > things look and you need to insert special things here and there, > using an FTL file for the whole thing is probably much better, and > probably even easier in many cases. It's harder, but not that hard... > > -David > > > On Jan 13, 2006, at 9:46 AM, Si Chen wrote: > >> David, >> >> What do you think of something like >> <include location="component://....ftl"> >> in the form widget, so that a block of FTL/HTML can be included right >> into the form. >> >> I think this would help with: >> 1. Allowing a mix of complex HTML and form widget stuff to be rendered >> together. Right now, you have to choose between the control of >> HTML/FTL >> or the ease of form-widget. >> 2. Allow repetitive things, like address entry stuff, to be reused >> across forms. >> 3. Allow for certain unique elements, like the stuff Alexandre Gomes >> was talking about, to be supported without adding all sorts of new tags >> to support them. >> >> Si >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev > > >------------------------------------------------------------------------ > > >_______________________________________________ >Dev mailing list >[hidden email] >http://lists.ofbiz.org/mailman/listinfo/dev > _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Yeah, that's kind of the idea, ie use the FTL as the "master" in that case. I consider BSH and FTL fairly different in their roles in life. I'm okay with BSH slipping into more places because it is really just a scripting language used for logic. The presentation part is where things get more interesting and difficult and where I try to be a little bit more careful about patterns... -David On Jan 13, 2006, at 10:11 AM, Si Chen wrote: > Actually, I thought you might like it. :) (Especially after I saw > the > bsh call inside the description="") > > But I think you have a good point. For really complex things it is > better to work form into FTL, rather than vice-versa. > > Thanks, > > Si > > David E. Jones wrote: > >> >> My initial reaction, as you might guess, is that I really don't like >> it. It breaks the semantics of the form widget and could potentially >> cause all sorts of problems in application. >> >> For now it is possible, and probably generally better, to just use >> the attributes to not include the form opening and/or closing and >> then from the screen widget include multiple forms interleaved as >> desired with FTL files. If you really need control over exactly how >> things look and you need to insert special things here and there, >> using an FTL file for the whole thing is probably much better, and >> probably even easier in many cases. It's harder, but not that hard... >> >> -David >> >> >> On Jan 13, 2006, at 9:46 AM, Si Chen wrote: >> >>> David, >>> >>> What do you think of something like >>> <include location="component://....ftl"> >>> in the form widget, so that a block of FTL/HTML can be included >>> right >>> into the form. >>> >>> I think this would help with: >>> 1. Allowing a mix of complex HTML and form widget stuff to be >>> rendered >>> together. Right now, you have to choose between the control of >>> HTML/FTL >>> or the ease of form-widget. >>> 2. Allow repetitive things, like address entry stuff, to be reused >>> across forms. >>> 3. Allow for certain unique elements, like the stuff Alexandre >>> Gomes >>> was talking about, to be supported without adding all sorts of >>> new tags >>> to support them. >>> >>> Si >>> >>> _______________________________________________ >>> Dev mailing list >>> [hidden email] >>> http://lists.ofbiz.org/mailman/listinfo/dev >> >> >> --------------------------------------------------------------------- >> --- >> >> >> _______________________________________________ >> Dev mailing list >> [hidden email] >> http://lists.ofbiz.org/mailman/listinfo/dev >> > > _______________________________________________ > Dev mailing list > [hidden email] > http://lists.ofbiz.org/mailman/listinfo/dev _______________________________________________ Dev mailing list [hidden email] http://lists.ofbiz.org/mailman/listinfo/dev |
Free forum by Nabble | Edit this page |