I can see that there are some very good points for not including html encoding of newline characters in the bean:write tag. I also think there are one or two good points for the opposite. Anyway, I've modified my solution a bit, so now it can be applied as a patch to the bean:write and nested:write tags.

There are 3 modified files:
- WriteTag.java
- struts-bean.tld
- struts-nested.tld

I've added an attribute, encodeLineFeed, that defaults to false. If true, all linebreaks are HTML encoded after any filtering of other HTML.

If anyone wants to use these, just send me a mail!

Inge :)



At 07:16 25.10.2002 -0400, you wrote:
10/25/2002 2:48:49 AM, Inge Solvoll <[EMAIL PROTECTED]> wrote:

>The current filter functionality that escapes html is also
basically
>functionality that could have been done by some tag in JSTL.
But for
>functionality that is very common, I think it is reasonable to
focus on
>convenience rather than design principles.

From my perspective, the "convenient" thing is for this
transformation tag to live in Jakarta Taglibs, where more
people can use it.

The original Struts taglibs were provided as a convenience. But
now that there are other places where these conveniences are
better hosted, we should encourage further development take
place in another forum (Jakarta Taglibs).

At least IMHO =:)

>If you agree with this, the interesting discussion here then
is:
>- What is the more common case when outputting text with the
bean:write
>tag? To view the text with visible linefeeds as inputted by
the user, or not?
>- Are there other filtering tasks that are equally common as
this? If there
>are, it would be less reasonable to insert linefeed filtering,
as you said,
>as it would cause a storm of filtering requests...
>- Is the need for filtering linefeeds as common as I think? Or
is my webapp
>an edge case?
>- Are there other Struts tag that this discussion applies to?

Which underscores my point. Going past the simple filter option
opens a Pandora's Box. The best place for a discussion this
interesting is Jakarta Taglibs, where they specialize in such
things.

IMHO, moving forward, the Struts tags should be about exposing
the Struts framework (as the HTML library does). Generic
functionality is better handled by other players, like JSTL,
JSF, and Jakarta Taglibs to fill any gaps in first two.

But, again, if someone develops a patch, and someone applies
it, I'll be +0 on enhancements to the original taglibs.

-Ted.



--
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>

Reply via email to