Re: Embedded bean/param values
Hi Devon, See below... [EMAIL PROTECTED] wrote: > > > JSPTL allows you to do the following by using the Simplest > > Possible Expression Language (SPEL) provided with the > > reference implementation: > > > > > > > > The above examples make things prettier but don't really > add much functionality over JSP expressions. The original > author in this thread was looking for something like: > > > > The problem is that the example isn't very good because it > is only a which is pretty much just a lookup > and can be handled with JSP expressions. But if we take > another example such as: > > "> > > The problem is clearer. The taglib adds some > significant functionality and isn't just a bean access. Stuff > like this has caused me endless frustration. > > If SPEL had some way of calling a taglib as if it were a > function, I'd be dancing on my desk. Something like: > > > > Seems like the hardest part of adding this is coming up with > a reasonable syntax. But I don't believe it's been done yet. > I do note, however, that that JSPTL provides a way of plugging > in expression languages. So maybe this will encourage future > experimentation in this direction. > > Devon Using your example: "> This could be done in JSPTL in the following way: Would that make you dance on your desk? ;-) -- Pierre >From the JSPTL docs: Setting the value of a JSP scoped attribute from the tag's body content is useful to solve the problem associated with the fact that a tag attribute's value cannot be set from a tag. In the past, a tag developer would have to offer extra "attributes as tags" so the value of these attributes could be set from other tags. For example: mumbojumbo With the tag, this can be handled without requiring the extra tag. mumbojumbo
Re: Embedded bean/param values
"Craig R. McClanahan" wrote: > > On Tue, 17 Jul 2001, Nino Walker wrote: > > > Hi, > > > > I've noticed a number of postings asking about syntax using embedded > > tags, a la: > > .../> > > > > It's clear that this is not supported, but has anyone implemented a > > different solution to address this? > > > > In case people aren't aware, it's a restriction in the JSP spec ... and, > the ultimate reason is that it's invalid XML syntax as well. > > > I'm coming form the world of ATG/JHTML, where they support syntax like: > > and > attribute="param:ParamName"> > > > > The standard approach to this requirment in JSP is to use runtime > expressions. Where you might want to write > > " /> > > you can write this instead: > > > > > > This has been very convenient, and I'm curious if there are solutions > > existing, or on the horizon, that solve this problem. Yes. Have a look at JSPTL (http://jakarta.apache.org/taglibs/doc/jsptl-doc/jsptl-ea1/index.html). JSPTL allows you to do the following by using the Simplest Possible Expression Language (SPEL) provided with the reference implementation: -- Pierre > > > > Thanks, > > > > Nino > > > > > > Craig
Re: some comparision between JSP/struts and velocity
Tim Colson wrote: > > Scriptlets OK for "view" only? > > Another developer in my group and I discussed this at length last week. I > believe scriptlets in the view to be "bad" practice...or at least a slippery > slope towards badness. > > I suggest that there are two levels of separation we are trying to achieve. > > 1) Separation of Business Logic from Display logic > 2) Separation of Developer tasks from Designer tasks > > I'd bet we all mostly agree and accept the first type as good MVC practice, > and Struts does this quite well. The second type, though, would be violated > by putting scriptlets into the View, something JSP does not prevent. > > While not violating MVC - the resulting View needs a Designer who knows > Java. > > The counter-argument usually goes like so, "Well, there's JavaScript on the > page, and the Designer understands that... and the JSP Scriptlet is Java > which kinda looks like JavaScript...ergo, the Designer should be okay with > that too." > > Slippery Slope. The Designer probably copied the JS from a Script archive, > or used a WYSIWIG tool like DreamWeaver to build the script... ;-) > > BTW - the scriptlet was written because the existing taglibs either couldn't > do what we needed, or at least it was taking too much time to figure out if > they could. If we had Velocity as an option, I could have written the > necessary bits without the complication of Java in short order. I'm not sure > the Designer would understand it, but I'm betting I'd have an easier time > explaining the minimal Velocity directives versus the Java > > Cheers, > Tim Colson Tim, The current work in JSR-052 (JSP standard tag library -- JSPTL) is trying to address some of these concerns. Namely, our first Early Access release on jakarta-taglibs (http://jakarta.apache.org/taglibs/doc/jsptl-doc/jsptl-ea1/index.html) introduces control flow tags (, , , ) as well as the concept of a simple expression language (with associated tags , , ) to simplify access to application data. The JSR-052 expert group would be really interested in hearing from people in the trenches. Please let us know if we are heading in the right direction. > If we had Velocity as an option, I could have written the > necessary bits without the complication of Java in short order. I'm not sure > the Designer would understand it, but I'm betting I'd have an easier time > explaining the minimal Velocity directives versus the Java In light of the current direction taken by JSPTL EA, could you tell us what your web designers would think of JSPTL? What improvements would be required to fit the bill? Thanks, -- Pierre
Re: "Eval" tag?
John Raley wrote: > Is there a tag (in struts or elsewhere) that will evaluate its body into > a String that can be squirreled away for later use? John, I'm just finishing implementing a tag library that may help you out. I shall submit it to jakarta-taglibs by the beginning of next week. My tentative name for the tag library is "IOAdapter". Its goal is to provide a generic mechanism by which a variety of input sources can be copied to a variety of output sinks, with an optional transformation applied on the input source before it is copied over. In your case, it would look something like the following: ... content ... If an "in" argument is not specified in the 'ioa' tag, input comes by default from the tag's body content. Would that fit your requirements? -- Pierre
Re: getting arrays w/ useBean?
Seth,
Simply add the scope attribute and it should then work.
-- Pierre
Seth Ladd wrote:
>
> Hello,
>
> I'm having a problem with referencing an array with . I keep
> getting ClassCastExceptions, and I'm not sure how exactly to do this.
>
> I gave the request an array of objects using request.setAttribute("id",
> myArray). When I reference this in my JSP page, I am trying to use
> something like:
>
>
>
> but it doesn't work. I have also tried different permutations of class and
> type using brackets or not. The goal is to get an array, from the request
> object to the taglib (which is really cool, btw!).
>
> If anyone can help me out, I would really appreciate it.
>
> Thanks very much in advance,
> Seth
>
> ps I eventually just didn't use and referenced the array
> directly with iterate, but now I'm really curious how to do it. :)
