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