Re: Some thoughts #2.

[Sudhaker Raj <su...@gmail.com>]

@ 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 <mf...@gmail.com> 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 <su...@gmail.com> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
> 
> 


-- 
Cheers,
Sudhaker Raj
http://thej2ee.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org