Hia everyone, just a small status update
I got most artefacts up and running
the only ones missing for now
are the components and renderers.
After that I will clean up and document everything.
So I assume the first results will be visible by next week.
(I am bound by day to day duties somewhat)
Sorry for not showcasing anything yet,
but I want to have a fully working cleaned up version
yet before sending the code out in the wild.
There has been a lot of experimenting going on
and some stuff internally is still a little bit messy.
Again if you want to have the code before,
just send me a private mail and I am happy to send it to you
(or open a download link)
Werner
Kito D. Mann schrieb:
Very cool, Werner!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann - Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
phone: +1 203-653-2989
fax: +1 203-653-2988
-----Original Message-----
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Werner Punz
Sent: Tuesday, May 13, 2008 1:46 AM
To: dev@myfaces.apache.org
Subject: myfaces groovy support
Hello everyone
I just wanted to give notification that I took a small break from my
components project which is still on track and that I am working on
myfaces groovy support.
I got the first artefacts already reloading, and a first code will
be made available by the end of the week, early next week.
(For the Sun guys reading, thanks a lot you gave me the final push to
do
it, although I did many things differently than you did)
Ok what will be done:
First of all I replaced all the factories with my own ones
to enable the entire system, I also had to write my own context
listener
to handle the classloader issues.
(We really need a change in the spec here to enable scripting properly
-
Ed?)
Secondly once the factories were in place I added proxy generation code
wherever needed to enable reloading proxies.
Third, a classloader which forks into the groovy system to load the
groovy code.
The groovy code also has its own reloading weaving code added to enable
reloading of groovy files on the groovy side of things (the woven aop
reloading code is lost on the java side however if you just deliver
classes instead of objects, my first approach was a try to enable
everything on the java side)
So what do we get
Reloading for most artefacts (probably on method level if things work
out the way I intend them to be (For certain artefacts
there are contracts you have to program in on the groovy side to enable
this - aka expose the private properties some artefacts have otherwise
a on method reloading will not be possible).
Maybe and this is a big maybe, if I can get it up and running (I want
to
replace code on the fly) reloading of methods on groovy classes loaded
by groovy over the new classloader.
Again this is a big if, I have not prototyped this fully yet, but it
should be possible.
The idea is, once you load an in groovy object over the classloader
it should be possible to change its methods on the fly via the meta
programming capabilities of groovy.
Ok first code around friday or early next week. After that I will start
further discussions.
And again, thanks to Ryan and Ed for finally pushing me towards it
(indirectly by doing it).
I also have to admit I have had a look at some parts of the code to
check how you guys solved some problems I have been facing - especially
the dreaded classloader issues and weaving issues.
(I did most of the stuff differently though due to the different
approach I am doing, of a mixed groovy/java infrastructure to enable
some things not reachable from the java side that easily, also I did
not
want to change the core code, I wanted to have it more as an
extension).
If you want to have a look at the code upfront
before next week, send me a private mail, I just do not want to post
it yet because it still is not done enough for a public post.
Especially the init code I am still very unhappy with.
Werner
