On 7/19/05, Aleksei Valikov <[EMAIL PROTECTED]> wrote:
> Hi.
>
> > Instead, IMHO, the expression language should encourage you to
> > manipulate server side model data with model tier techniques ... it
> > was designed to serve as a *binding* between the tiers, rather than as
> > a general purpose computational technology. If we had wanted that, we
> > would likely have adopted essentially the entire JavaScript language
> > as the expression language mechanism in the first place (it was
> > considered and rejected during the initial deliberations in the JSTL
> > expert group, for the reasons outlined above).
>
> Well, probably I'm missing something.
> Here's a simple example. I have a documentDao with the possibility to
> load document and give back the document list. I want to display a
> table, where rows correspond to the documents returned by the dao. In
> every row, I'd like to have a "Load" button to load the corresponding
> document.
> With JS in EL it is as easy as #{[documentDao.load(document)]} as a
> button action.
>
> What would be the easiest way to implement this with standard EL,
> without JS?
>
I would have my application invoke some business logic that gathered
together the data needed, and exposed it as a request attribute --
then, the EL expression is just a simple variable reference.
I can see why you think this would be valuable. To me, though, this
approach is mixing functional logic (telling the back end something
about what data to retrieve, via the parameters to the methods) and
presentation logic (defining how the rendering should occur). I've
seen enough people screw this up with scriptlets ... it's a path I
would prefer not to go down again :-).
Craig
