Same approach for taglibs. I created a <custom:label> tag that borrowed a little code from <bean:message> but did other things like change the style if the field known by the key was in error and put an asterisk there if the field was required by Validator. I have not needed this for <bean:write> but perhaps the same technique of shadowing/wrapping/shielding your app with a <custom:write> tag but steal the code from <bean:write> to do what you want that it doesn't currently do. In our environment, we could easily create a <bean:write> replacement and apply it globally across all pages with an IntelliJ find/replace in path and be done with it :)
Erik
Ted Husted wrote:
IMHO, once we opened the door past the filter attribute, people would suggest that we start adding this or that to the bean write tag as well.
I would say that any transformations beyond the escape filter really belong on some other tag.
IMHO, a better place for a tag like this is Taglibs. This functionality does not involve the core framework directly, and the effort may get more exposure in taglibs than here.
Also, IMHO, we should encourage people to look to Taglibs for general-purpose tags. Post 1.1, we might seriously consider migrating the bean, logic, tile, and template packages to Taglibs (if they will have them), where it can stand toe-to-
toe with JSTL.
This would let us focus on the HTML tags that interact with the framework, and leave the generic functionality to the (other) Jakarta community that specializes in such things.
But if someone supplies the patch, and a Committer applies it, like Craig, I'm +0 on the deal.
-Ted.
10/24/2002 5:12:19 AM, Inge Solvoll <[EMAIL PROTECTED]> wrote:
I actually didn't think of creating a tag thatcan be wrapped around the
bean:write tag, that's obviously the bestsolution for me. I'll check if
there is something like that in Jakarta taglib. Ibelieve someone here
mentioned a 'replace' tag.question. The web application I'm
But, for me this is still an interesting
working on is very big and has a lot of textinput and output. All of our
inputted text should preserve linebreaks. Textentered in regular text
fields doesn't have linebreaks anyway, and textfrom textareas should have
breaks. I see that it isn't too pretty code toalways insert BR-tags in
bean:write, but couldn't this at least be anoption, like this:bean:write name="myBean" property="myProp"preserveLineFeed="false",where preserveLineFeed would be true by default?The tag would then use a
method like the breakNewlines(String) methodsuggested below.For my web application this would be far moreelegant than wrapping another
custom tag around every single bean:write thatneeds to preserve line
breaks. As I said, the need to preservelinebreaks is very common in my
experience, I rarely want to NOT preservelinebreaks... At least for me
because most of the text that is outputted istext inputted by a user in a
textfield or textarea."filter" that escapes
The bean:write tag already has an attribute
HTML-formatting, which in my opinion covers thesame kind of thing, how the
output looks when rendered in html, why is it notelegant to do the same
transformation, aren't there?thing for linebreaks? At 12:02 23.10.2002 -0500, you wrote:There are already taglibs that do this
address this? Is there a wayDoesn't the taglibs project have things that
a method to Action liketo do this using the JSTL (Martin?)? David Graham wrote:If this is a common problem, maybe we could add
transformation. The <bean:write>breakNewLines(String) that does this
tag should not do any transformation, justdisplay what it's given.What do you think? Dave-- Eddie Bush -- To unsubscribe, e-mail: <mailto:struts-dev-[EMAIL PROTECTED]>For additional commands, e-mail: <mailto:struts-[EMAIL PROTECTED]>-- To unsubscribe, e-mail: <mailto:struts-dev-[EMAIL PROTECTED]>For additional commands, e-mail: <mailto:struts-[EMAIL PROTECTED]>-- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
-- To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>