@ my suggestion #2 It was not fully cooked idea and I just popped it for the sake of discussion.
We developed a similar framework in one of our previous project where we were using widgets kind of control for each HTML form element. For example: If some field is set to use currency widget, then in edit mode it was rendering a DHTML powered right-aligned textbox, which has inbuilt and atomic capability of prefixing $ and adding comma etc (business really liked it). In view mode it was simply a label with currency formatting in our standard format. Similarly date selector was rendering another widget with textbox followed by a calendar icon. Needless to say, that icon was popping a DHTML calendar and filling date textbox. In view mode it was a label with just formatted date. In case of a multi-line field (say comments), edit mode was rendering a standard textarea and view mode was rendering html code with all NL replaced with <br /> !!! The whole interface was themed for our application and we had a group of rendering styles to choose from for every form field. It was a very powerful and still simple to use framework. - The port of the same in struts world can to be a new taglib with formdef like plug-in where you can define your rendering component declaratively and pass dirty job of rendering HTML to this taglib. All corporate have some UI standards as well and making (customizing) a superset of widgets and style should not be any problem. I agree this won't solve every problem out-of-box, but guess no one can. Thanks for your inputs. On 8/29/05, Martin Cooper <[EMAIL PROTECTED]> wrote: > The form modes sound nice in theory, but I suspect you'd end up having to > write multiple renderings by hand anyway. I assume that the purpose was to > avoid this. > > For example, how would a non-editable checkbox be rendered? Yes/No? On/Off? > A green tick and a red cross? What about the result of a set of grouped > checkboxes? (You'd presumably have to add a tag to indicate that they are a > group, also.) A group of radio buttons? People are going to want to have > control over these things, and I find it hard to imagine how that would be > done without a multitude of attributes and options. It would end up being > simpler to just write separate renderings. > > -- > Martin Cooper > > > On 8/29/05, Sudhaker Raj <[EMAIL PROTECTED]> wrote: > > > > 1. Do we have need of tags like these? > > > > <html:js src="/script/util.js" /> > > <html:css src="/css/style.css" /> > > > > Currently we are suppose to use html:rewrite tag or some crud method. > > > > <script language="javascript" src="<html:rewrite src="/script/util.js" > > />"></script> > > > > CSS is bit neat because of @import but JS is still making code look nasty. > > > > > > 2. Do we have need of tag attribute like this? > > > > <html:form mode="edit"> > > ... > > </html:form> > > > > <html:form mode="confirm"> > > ... > > </html:form> > > > > <html:form mode="show"> > > ... > > </html:form> > > > > Setting the mode attribute to 'confirm' will convert all form-field > > into a hidden field and will replace all editable area with a label > > showing current values. Similarly setting mode attribute to 'show' > > will simply replace all editable area with a label showing current > > values. > > > > The show mode can be very well used for followings > > > > * Same JSP code can be used to show details and edit details. > > * Confirm filled values before finally submitting. > > * Form can be made read-only or editable based on user's credentials. > > > > This can be further improved to control field level rendering and > > security. > > > > -- > > Cheers, > > Sudhaker Raj > > http://thej2ee.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > -- Cheers, Sudhaker Raj http://thej2ee.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
