|
From: Cristian P. <psc...@ya...> - 2006-03-30 09:01:40
|
[I have been tring to send this mail as a reply from my subcription email address but is seams there are some technical problems]
Thank you again for your replies! There have been a lot of thoughts on
the wedge framework in your messages. More than I expected! This
motivates me and, in the same time, I see it as a challenge!
Trying to summarize your advices, for the moment, I come with this
conclusions:
1. I have given a close look to this ASM tool (http://asm.objectweb.org)
and it looks quite nice to me. It will not be too hard to use it. I just
need to get more familliar with bytecode generation :-) . A custom
class loader for the generated mapping classes will help us on
regenerating and reloading these classes as templates change. The beans
behind the pages may be reloaded if the application was started in debug
mode.
2. The generation of byte code instead of java source code seams like a
better idea. But what I see as a problem is how easy would be to debug
such a code since it is a lot of code that we generate. I don't know if
the price is not too much just to gain that 10 seconds spent on java
source generation and compilation. (for an application of 250 pages,
with proper optimizations, with selective regeneration, it would not
take too long either).
3. About providing a script that will start a wedge runtime. It is a
very good idea but, again, I think it can wait until the framework will
be stable enough for developer preview or even for development.
4. On Steven Devijver example:
<wedge:request uri="/personDetail" method="personMapperBean.findPersonById(id)"/>
This looks to me more like a "page flow framework" than a component centric one. As much as possible, the developer should not be aware of url's and request parameters. Currently, events are handled like this: In the 'action' attribute of a form or a link you specify the method that should called, e.g.
<form action="savePerson()" ... >
that will be translated into: mapperBean.savePerson()
The data from the form will be mapped into the Person bean which will be saved by the savePerson() method. Or even better. If the mapper (which is Spring managed bean) has a personService one can specify in the form action somethink like:
<form action="personService.savePerson(person)" ... >
that will be translated into: mapperBean.getPersonService().savePerson(mapperBean.getPerson())
Excuse me if I have not understand your advice right.
5. About the configuration file: following your advice I came up with this:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:wdg="http://wedge.sourceforge.net/schema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans
http://wedge.sourceforge.net/schema
http://wedge.sourceforge.net/schema">
<bean name="customerService" class="wedge.test.service.CustomerService" />
<wdg:frame name="main-frame" class="wedge.test.web.MainFrame" [uri="main-frame.html"]>
<property name="customerService" ref="customerService" />
</wdg:frame>
<wdg:page name="home" class="wedge.test.web.HomePage" frame="main-frame" [uri="home.html"]>
<property name="customerService" ref="customerService" />
</wdg:page>
</beans>
wdg:page, wdg:frame or wdg:part are wedge components (pages, frames or simple components) that will be directly configured as Spring beans. Wedge handlers for this elements will register these bean definitions and also the coresponding wedge component specification. Thus will have configuration in one place and conventions out of the box! ;-) How this looks to you?
Thank you again for your time and interest!
Cristian
---------------------------------
New Yahoo! Messenger with Voice. Call regular phones from your PC for low, low rates. |