more JSP author control over the HTML produced by mak: tags

[ghost]

Reported by @frederikhabils on 11 Nov 2002 13:15 UTC at present, it seems to be impossible to add standard HTML (or CSS or JS) to makumba tags. I guess that separation mak:tag and it's html representation can be desirable.

But there are cases where adding HTML (etc) to tags can be desirable: I think especially of adding e.g. JS onChange handlers to mak:input or CSS class="...", again to mak:input.

I've encountered this a few times, last when there was a request to have the font of the password edit box in admin area to use a more readable (non- standard font) (to distinguish I, 1, l, etc). The only way out is to use CSS (IMO). But I can't add the CSS inline, nor can I mention the class of the HTML element that will be constructed out of the mak:input.

Migrated-From: http://trac.makumba.org/ticket/101

[ghost]

Comment by @cristianbogdan on 11 Nov 2002 13:45 UTC WORKAROUND the easy workaround for this, especially for simple text fields is to do the by hand, using display=false

ON FIXING THIS adding the possibility to have html="onChange blabla" attribute to e.g. mak:input should be quite easy even today. makumba would just add that inside the generated without caring about it. i'd like smb else to do that, though.

a bit more complex would be <mak:input ...> onChange blabla </mak:html></mak:input>

this would eliminate the need to escape double quotes like \" not sure of other benefits

[ghost]

Comment by @stefanb on 11 Nov 2002 13:52 UTC What cristi proposes in comment 1 is probably as generic as it could be, but far from what html programers would want IMHO

All makumba tags should probably pass some extra parameters to the generated html.

what would those common html parameters be? class style onChange ...?

so that jsp hacker could just write:

(this would need to add a around the value)

I think it is easily doable by adding them to a father of all makumba tags, MakumbaTag.java

[ghost]

Comment by @cristianbogdan on 11 Nov 2002 15:26 UTC yes, having the actual HTML tag attrbibutes seems to be better than having "html=". we already have these for other HTML tag attributes. indeed, adding tag attributes to MakumbaTag is a way to go.

the second part of the job is to decide which makumba tags should accept these attributes, and modify servlet_context/makumba.tld accordingly. they can be rtexprvalues (i.e. can be indicated by <%= scriplets %> )

the third part of the job is to make the respective makumba tags actually reprint the respective attributes to their HTML output.

the fourth and final part of the job is to update the documentation good luck ;)

[ghost]

Comment by @cristianbogdan on 22 Apr 2003 09:56 UTC Bug 394 has been marked as a duplicate of this bug.

[ghost]

Comment by @cristianbogdan on 22 May 2003 20:14 UTC there are some changes in the noTrLoops branch that affect the fix of this bug (the present getRootQueryBuffer() method should be replaced with the params field). so the branch needs be joined (note that a branch can be joined more than once) before the fix of this bug (or the bug can be fixed on the branch, or on a branch of the branch)

in any case, the fix is pretty easy. please provide this info

• what html attributes
• to which tags (value, input?)
• what would they translate into? <font ...>value ?

[ghost]

Comment by @cristianbogdan on 23 Jun 2003 11:48 UTC Bug 494 has been marked as a duplicate of this bug.

[ghost]

Comment by @cristianbogdan on 23 Jun 2003 11:50 UTC Raul said: I have found out that it next to impossible to add CSS styles and classes to makumba input tags. While not a critical problem this has efects on the design - and sometimes you have to use standard forms(via mak:form) and normal HTML imput just to add styles to your site.

Useful tags would be: id, class and style(could be more i guess).

id is more and more used in javascripts, beeing an object and not just a name.

I belive now(0.5.9) it the perfect time to solve this small problem

[ghost]

Comment by Raul.Firu@best.eu.org on 23 Jun 2003 12:12 UTC Some more comments(not that i read all of them)

i belive the most user-frendly way would be just to allow all other HTML specific(and JS specific) parameters in the mak:input tags

I agree with Stefan that most of them are style,class,id,onChange.

But is it a way to allow anything else that is not mak specific to pe assed back to pe interperted on client side? Why i'm asking this is becouse it is more and more a practice to have your ouwn JavaScript-interpreted inout paramaters some exmples:

<input name="a" mandatory="true" errMsg="Bla" ....>

[ghost]

Comment by @cristianbogdan on 23 Jun 2003 12:30 UTC

But is it a way to allow anything else that is not mak specific to pe assed back to pe interperted on client side?

interesting choice of words :)))

anyway, i guess the only way is to have extraHtml='name1="val1" name2="val2"...' (note that ' is used in order not to have to escape the ", i think that normally works)

but i agree that the standard ones (style, class, onChange) should be supported directly, without extraHtml...

some questions:

• is this only for mak:input? we can leave mak:value for later anyway.
• there may be a problem with id= at JSP level because id= has another function in JSP. how serious is that? but if extraHtml is implemented, that will not be a problem anyway
• this should be ignored if the field is indicated as "hidden" right?
• in all other cases, all these attributes should be copied "as is" to the output, right?

[ghost]

Comment by Raul.Firu@best.eu.org on 23 Jun 2003 12:45 UTC

interesting choice of words :))) I know - but it was 2 late :(

anyway, i guess the only way is to have extraHtml='name1="val1" name2="val2"...' (note that ' is used in order not to have to escape the ", i think that normally works) I think this is great - and general enough

but i agree that the standard ones (style, class, onChange) should be supported directly, without extraHtml... it doesn't matter how are they supported - i think there should be one rule for all - not to be cofusing.

some questions:

• is this only for mak:input? we can leave mak:value for later anyway. only mak:input i belive, since mak:value is "raw" text - so any special tags can be inserted.(i guess you can print

  if that's what you have in the db)

• there may be a problem with id= at JSP level because id= has another function in JSP. how serious is that? but if extraHtml is implemented, that will not be a problem anyway quite big since all custom tags and new js functions depend on this. i'm not sure if smth like document.all("myInput").myTag works(insted document.all.myInput.myTag) - i guess the difference between name and id is clear from my example

• this should be ignored if the field is indicated as "hidden" right? nope - i don't know have a clear exmaple now, but you should be bacle to have a tag even for hidden inputs(even if it is just to count it or smth).

• in all other cases, all these attributes should be copied "as is" to the output, right? yup

[ghost]

Comment by @stefanb on 23 Jun 2003 13:00 UTC If you don't want to specify new, same style for all input controls, but only some, in some pages, you can use descendant selectors of the CSS, described at: http://www.w3.org/TR/CSS21/selector.html#descendant-selectors

eg specifying a style: .wickedFormat input[type=text] {background-color:red} .wickedFormat select {background-color:blue} .wickedFormat textarea {background-color:pink}

then surrounding normal makumba tags in a span of "super-style"

will (should :) render the contols in the desired style.

Of course this is just a workaround.... will go trough html spec to see what are the most common attributes that need to be supported.

[ghost]

Comment by @stefanb on 23 Jun 2003 13:55 UTC Going trough a list of valid/possible HTML tag attributes http://www.w3.org/TR/html401/index/attributes.html a)normal html that makumba generates could use: id class title style onClick onDblClick onKeyDown onKeyPress onKeyUp onMouseDown onMouseMove onMouseOut onMouseOver onMouseUp

b)Additionally (to a)), input controls can have: accept accesskey disabled onChange onBlur onFocus onSelect tabIndex

c)

tag has (in addition to a))also: onReset onSubmit target name (all input controls are already utilizing it...should it be allowed to rename them there too?)

did i overlook something important? is there too much? something not practical?

[ghost]

Comment by @cristianbogdan on 23 Jun 2003 14:21 UTC hmmm after comment 12 it looks simpler to have extraHtml=.... instead of supporting all those

id= seems to be important (comment 10) and it might not work. shall i try that and then make a decission for the others? if it works i will implement 2-3 of them and let others develop the whole thing further...

comment 10:

• this should be ignored if the field is indicated as "hidden" right? nope - i don't know have a clear exmaple now, but you should be bacle to have a tag even for hidden inputs(even if it is just to count it or smth).

i don't get it: if the field is hidden, formatting doesn't matter, so why would those CSS things matter? i still think the CSS stuff should be ignored if the field is hidden. the hidden field is rendered by makumba, i just can't see where these css attributes will matter

[ghost]

Comment by @stefanb on 23 Jun 2003 14:49 UTC should not be as tricky as it might seem what they need to do is just concatenate strings to the existing(?) extraHtml param, eg: public void setAccesKey(String s) {extraHtml="accessKey=\""+s+"\" "+extraHtml;} ...or sth similar... and they need to be mentioned in TLD at every tag

surely much easier than putting some javascript in extraHtml parameter and dealing with escaping quotes, backslashes, validation regexps,... twice.

probably name for id html attribute would need to be renamed in jsp to avoid conflicts there

[ghost]

Comment by @frederikhabils on 23 Jun 2003 22:17 UTC I've been trying to do some clever thinking about this problem, but I didn't get far ;-/

Anyway, Comment 11 is pretty clever workaround for many cases, neat ;-)

About comment 12 to 14: I stumbled upon "jakarta struts", which looks a bit like makumba, but is differently oriented nevertheless. The interesting thing is the html taglib, that generates HTML tags.

• start point http://jakarta.apache.org/struts/index.html

• specific HTML support (html taglib) http://jakarta.apache.org/struts/userGuide/struts-html.html http://jakarta.apache.org/struts/api/org/apache/struts/taglib/html/package- summary.html#package_description

• The tag that has support for all these html attributes: http://jakarta.apache.org/struts/api/org/apache/struts/taglib/html/BaseHandlerT ag.html

• Downloadable sources: http://www.apache.org/dist/jakarta/struts/source/

Of course, there's plenty to say about the differences, but the interesting point is the support for a very wide range of html attributes in the tags.

Personally, I guess that supporting all these tag attributes separately, creates a major explosion of (largely simple) code in makumba.

So, looking at the alternatives again:

• Nested html tag.

  onChange="validate();" style="color:red"

• input tag body content.

  onChange="validate();" style="color:red"

• input tag htmlExtra attribute (i prefer naming 'htmlParams')

• input tag, many attributes

My Opinion (I have to admit being in a state of flux on this):

• support for attributes style, class, and id (perhaps by other name) directly. -> simple and direct, for most common cases. -> add support for others that are frequently used, on future demand. (onChange, onSubmit, ...?)

• all other through a nested (or ) -> general and easy to use/read for all other html extra's

And how to use it? -> form: add it on <form ...> html output of <mak:form ...> -> input: idem, form -> value: add it to <span ...> to go around the value. Question. If value is null, or simply blank, do we still generate the ? If yes, there is not really a reason to support the html-support on the mak:value tag. Mak-user can just type it himself around the mak:value.

[ghost]

Comment by @cristianbogdan on 24 Jun 2003 13:04 UTC comment 14

should not be as tricky as it might seem what they need to do is just concatenate strings to the existing(?) extraHtml param, eg:

it's not that easy, because after you computed extraHtml you need to pass them to the formatters. support for html attributes that are copied verbatim to the output does not exist at the moment. but it's clear that it needs be added

comment 15:

about id: the Struts example from Fred seems to use styleId=" " instead. is that correct, and should we adopt that?

about nested input tag and input tag with body content: i'll try to change the architecture a bit so they become possible. the formatter may format in two steps, and the tag can do something in between those steps (like add extra html, etc).

for mak:input, the first step would print "<input ...." and the end-step will print ">" letting extra html attributes be added inbetween

not sure how that will work with chooser options (see also bug 60) but i guess the first step can print "<select ....." and the end-step can check if s were added, and if not, print the default set of options and . or maybe a middle (end-header) step is needed as well?

i'll see, in any case i think supporting in-body formatting is very versatile and the present formatter architecture is obstructing that a bit

about using this in mak:value, there are no serious reasons not to use it. it is easy to detect if the value was null and decissions can be made based on that. let us do the inputs first, and then we look at mak:value

[ghost]

Comment by @cristianbogdan on 24 Jun 2003 13:16 UTC comment 8

Why i'm asking this is becouse it is more and more a practice to have your ouwn JavaScript-interpreted inout paramaters some exmples:

<input name="a" mandatory="true" errMsg="Bla" ....>

i think i saw that JSP 2.0 allows parameters that were not declared in the TLD but i might be wrong. you may want to check

anyway, this can be solved by having <mak:input ....>mandatory="true" errMsg="Bla"</mak:input> as proposed in comment 15

[ghost]

Comment by @cristianbogdan on 26 Jun 2003 09:34 UTC i said

id works (at least with jasper1) but surprisingly class doesn't! jasper1 complains that it can't find the setter method setClass() but i'm sure it was there. shall we adopt the struts convention styleClass and styleId?

since there is a much better use for id= (bug 58 comment 2) and since there don't seem to be other opinions, i will introduce support for styleClass and styleId at the next makumba version

since style, id and class are the most important and others are easy to add, don't expect me to do more on this.

you may want to give feedback on this question:

i have a slight problem with date: it generates a number of input controls. should the style, id, etc be applied to all of them? it is now.

[ghost]

Comment by @cristianbogdan on 24 Sep 2003 19:28 UTC Ovidiu complained the other day about the lack of target= for forms

is this bug too simple to be fixed, not challenging enough? :)

[ghost]

Comment by @stefanb on 25 Sep 2003 08:22 UTC Cristi wrote in comment 19:

don't seem to be other opinions, i will introduce support for styleClass and styleId at the next makumba version And that could be the reason for others not to deal with this issue.

Greping the sources for styleClass or styleId gives no matches.

I also have slight problem patching current HEAD with patch in attachment 28. stefan@tequila:~/bundle/sources/makumba$ patch -c -p1 -i makumba/bug101-extraformating-28.patch gives mostly failures/rejects.

Would unified diff be better or should it be applied on some specific branch? Or is the patch just outdated beyond usability?

[ghost]

Comment by @frederikhabils on 25 Sep 2003 08:36 UTC comment 21:

Greping the sources for styleClass or styleId gives no matches.

actually, makumbaTag.java has setter methods for these. They are stored in StringBuffer extraFormatting

And at least some *Editor classes in controller.html package, print this out...

So, maybe all that is needed, is to add this to the Tag.java classes that make the mak:form's

// probably my last msg till 5 oct

[ghost]

Comment by @stefanb on 25 Sep 2003 08:55 UTC (From update of attachment 28) oops, I was grepping case sensitive and reducing the pattern to simply "class" or "id" gave to many hits :)

Checked quickly the content of the patch and all of it seems to be committed to the MAIN branch, which makes attachment 28 obsolete.

//Xalara ! :)

[ghost]

Comment by @cristianbogdan on 25 Sep 2003 09:00 UTC comment 12 lists all attributes that should be added before this can be closed. i think whoever fixes this should add the attributes to MakumbaTag (around line 247, revision 2.7), with inspiration from the "style" attribute. that way, all other tags will inherit them, and makumba.tld should only allow the attributes at the tags where they make sense.

[ghost]

Comment by @stefanb on 25 Sep 2003 09:12 UTC yep, doing exactly that now that i know styleId is already in.

[ghost]

Comment by @stefanb on 25 Sep 2003 18:03 UTC Added all other parameters from comment 12, tested few a bit, seems to work just nicely. Enjoy!

Checking in CHANGELOG.txt; /usr/local/cvsroot/makumba/CHANGELOG.txt,v <-- CHANGELOG.txt new revision: 2.30; previous revision: 2.29 done Checking in classes/org/makumba/controller/html/FormResponder.java; /usr/local/cvsroot/makumba/classes/org/makumba/controller/html/FormResponder.java,v <-- FormResponder.java new revision: 2.3; previous revision: 2.2 done Checking in classes/org/makumba/view/jsptaglib/FormTagBase.java; /usr/local/cvsroot/makumba/classes/org/makumba/view/jsptaglib/FormTagBase.java,v <-- FormTagBase.java new revision: 2.3; previous revision: 2.2 done Checking in classes/org/makumba/view/jsptaglib/InputTag.java; /usr/local/cvsroot/makumba/classes/org/makumba/view/jsptaglib/InputTag.java,v <-- InputTag.java new revision: 2.2; previous revision: 2.1 done Checking in classes/org/makumba/view/jsptaglib/MakumbaTag.java; /usr/local/cvsroot/makumba/classes/org/makumba/view/jsptaglib/MakumbaTag.java,v <-- MakumbaTag.java new revision: 2.8; previous revision: 2.7 done Checking in servlet_context/WEB-INF/makumba.tld; /usr/local/cvsroot/makumba/servlet_context/WEB-INF/makumba.tld,v <-- makumba.tld new revision: 2.9; previous revision: 2.8 done

Still needs to be documented!

[ghost]

Comment by @stefanb on 7 Oct 2003 14:25 UTC changed .tld so that deleteLink now also has: name, styleId, styleClass, style (tested and works)

Documented all new attributes in makumba-spec.html