[S2] Avoiding usage of struts-tags
Hello Everyone,
do you know if the communication between the S2 Action and the
struts-tags is standardised? Or am I opening a black box if I replace
sth. like
s:textarea id=description name=object.description cols=40 rows=6/
with a VanillaHTML+JSTL version like
textarea id=description name=object.description cols=40
rows=6${object.description}/textarea
?
It is currently working; but can I rely on it?
Do you know how the field- and action-errors can be accessed with JSTL-EL?
The reason I do this is because I don't like the struts-tags and OGNL.
Thanx in advance,
~Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Avoiding usage of struts-tags
Andreas Mähler wrote:
Hello Everyone,
do you know if the communication between the S2 Action and the
struts-tags is standardised? Or am I opening a black box if I replace
sth. like
s:textarea id=description name=object.description cols=40
rows=6/
with a VanillaHTML+JSTL version like
textarea id=description name=object.description cols=40
rows=6${object.description}/textarea
?
This approach is okay. You will struggle with collections though (like
populating the values of a select)
An edge case is radio buttons as they include a hidden field (or was
that checkboxes). Just check the templates for what they render as html.
It is currently working; but can I rely on it?
Do you know how the field- and action-errors can be accessed with
JSTL-EL?
${actionErrors} is a CollectionString
${actionMessages} is a CollectionString
${fieldErrors} is a MapString, ListString where the key is the name
of the field
The reason I do this is because I don't like the struts-tags and OGNL.
That's understandable, but the template system of the tags is quite good
and it may be more productive to create better templates.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Avoiding usage of struts-tags
Thank you for your quick answer, Jeromy!
Jeromy Evans schrieb:
do you know if the communication between the S2 Action and the
struts-tags is standardised? Or am I opening a black box if I replace
sth. like
s:textarea id=description name=object.description cols=40
rows=6/
with a VanillaHTML+JSTL version like
textarea id=description name=object.description cols=40
rows=6${object.description}/textarea
?
This approach is okay. You will struggle with collections though (like
populating the values of a select)
An edge case is radio buttons as they include a hidden field (or was
that checkboxes). Just check the templates for what they render as html.
It was the checkboxes - i know about this issue (CheckboxInterceptor)
and i think that I can handle it :-) Haven't tried to replace
Collection-backed tags like s:select yet, but I think (using c:forEach)
it shouldn't be too painful aswell.
The reason I do this is because I don't like the struts-tags and OGNL.
That's understandable, but the template system of the tags is quite good
and it may be more productive to create better templates.
I've already tried that, but I don't know Freemaker yet and I don't even
like the code that is generated by the simple theme. (e.g: it was my
intention to write a 100% JavaScript-free webinterface) I also think
that the interface is quirky and not as straightforward as JSTL's (at
least the core tags - i rarely use the other stuff) - but that's just my
opinion. I think I've also discovered a bug in the s:colgroup tag, so I
can't use it. I've opened a ticket[1], but I think that I'm not allowed
to schedule it to - say - the 2.1.3 release (at least if I don't provide
a patch).
Greetings,
~Andreas
[1] https://issues.apache.org/struts/browse/WW-2758
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Avoiding usage of struts-tags
Andreas Mähler wrote: I've already tried that, but I don't know Freemaker yet and I don't even like the code that is generated by the simple theme. (e.g: it was my intention to write a 100% JavaScript-free webinterface) I also think that the interface is quirky and not as straightforward as JSTL's (at least the core tags - i rarely use the other stuff) - but that's just my opinion. I think I've also discovered a bug in the s:colgroup tag, so I can't use it. I've opened a ticket[1], but I think that I'm not allowed to schedule it to - say - the 2.1.3 release (at least if I don't provide a patch). Greetings, ~Andreas I didn't even know s:colgroup existed. I've been through the same pain and have many times started writing new tag implementations (less optional attributes, leaner templates) but its much larger than I expected. Even though I dislike the tags too, they do have many things going for them to the credit of the original developers; automatically include field errors in the right place and (usually) selecting the correct option in a select, populating values from collections etc. Complex forms become a mess if you don't use them. FreeMarker is overwhelming at first because the numerous #rt tags distracting from the important fields. I threw together this tool (http://www.freemarker-tool.com/) specifically for tweaking struts2 tag templates (see the examples). In one of my projects, prior to struts 2.0.9, I created a lot of JSP tags (.tag files) that wrapped struts2 simple tags with more behaviour/markup. eg. textfields that included a radio button to enable it first and an attribute to set the radio value. In 2.0.9 EL in struts2 tags was disallowed so eventually I had to rewrite them as custom struts 2 tags. Creating the new tags and templates was surprisingly straight-forward and definitely more productive that copy pasting the relevant JSP into every page. Anyway, hopefully just giving you some ideas. cheers, Jeromy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [S2] Avoiding usage of struts-tags
Hello! Jeromy Evans schrieb: I didn't even know s:colgroup existed. Whoops ;-) s:optgroup is what I meant It's 3 in the morning here in GER and I am still working at my diploma thesis... should go to sleep now :-) Thanx for the hints, ~Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
