Re: Trails 1.2 & OGNL issues

> On Mon, May 5, 2008 at 3:22 PM, Alejandro Scandroli
> <alejandroscandroli@...> wrote:
>
> >
> > I've been testing Trails 1.2 for a while (over two months) now, and
> > OGNL is giving me a huge headache.
> >
> > Although there are workarounds for all of them and they seem like not
> > so big a deal, they are huge when you depend on Trails development
> > speed and you have to spent most of your time working around these
> > issues.
> > On this particular project we are planning to move to T5 asap, but I
> > wonder what to do with the Trails 1.2 release.
> > What should we do?
> >
> > We can't revert back to OGNL 2.6.x.
> > We can't use tapestry-prop.
> > We could remove all the "defaultValue"s and we could declare
> > interfaces for every known property (eg: classDescriptor,
> > propertyDescriptor, model, modelNew, blockFinder) but that's way too
> > verbose.
> > We could disable caching (org.apache.tapestry.disable-caching=true)
> > but that will not perform well at all.
> > We could wait until OGNL enables a "don't ever compile" option.
> > We could release 1.2 anyway
> >
> >
>
> I'm using 1.2-SNAPSHOTs. I think we should release 1.2 anyway, and just
> properly document (and link to OGNL documentation that explains) compiled
> expressions and why you can and should always use #this when a compiled
> expression doesn't work. I know that compiled OGNL and using mixed types
> doesn't work and it's given me headaches as well, but I'm not willing to let
> go of the improved performance that compiled OGNL brings for the majority of
> the use cases. Disabling caching is not an option for other than
> development; when disabled, it'll pollute permgen space over time no matter
> how big it is.
>
> Kalle
>