|
From: Steven D. <ste...@gm...> - 2006-03-25 22:26:42
|
On 3/25/06, Seth Ladd <set...@gm...> wrote:
> > Yes, you need to restart the application and regenerate the code as you
> > make changes to the pages. But:
> > 1. I use jetty as an embedded server which is very practical and rapid
> > way to develop application. It does not take to much time to restart th=
e
> > server.
>
> Then might I recommend that if it doesn't already exist, provide an
> ant runtime for your application, and bundle Jetty. That is, make it
> *insanely* easy to start a new wedge runtime. Part of what a modern
> Java web framework must do, imho, is provide everything you need to
> get started out of the box. This includes the scripts to start and
> stop the app. In other words, wedge should be a self bundled and
> integrated package, not Yet Another Servlet with XML Config. See how
> Rails works with its 'ruby scripts/server'. There should be something
> like 'ant server'.
>
> > 2. I've made the ANT task only for generating the pages. The generation
> > requires all the application to be on the class path such that I start =
a
> > new java process to do that. This takes time, about 5 sec for my 5 page=
s
> > app. With the following code the time reduces to 1 sec.
>
> What about 250 pages? Does it only generate code for pages that have cha=
nged?
>
> > About defaults and conventions, I have been thinking to introduce them.
> > But still, I need a way to figure out which spring beans are wedge
> > components and which are not. More, you are not bound to spring, you ca=
n
>
> For simplicity's sake, I would bind it to Spring. Why make it
> optional? The more conventions the easier it is to learn and build
> things. If someone wants to rip out Spring, they can do the work. I
> wouldn't err on the side of pluggability at this stage in the game, I
> would focus on ease of use and quickness of development.
>
> > specify any kind of path that XmlWebApplicationContext can manage. The
> > file name is not always suitable for being an id
>
> This is where conventions kick in. First, you look for the bean in
> the ApplicationContext. If you don't find it, you can delegate to
> some sort of Resolver that knows how to do the mapping. The important
> part is, you first try the rule.
>
Amen. For me http://host/myapp/home should point to the 'home' bean in
Spring and map to /WEB-INF/home.html. These are two conventions that
are easy to implement and easy to overwrite. And as a consequence, no
XML for most configurations.
Another remark about the generation of the mapping between controller
and html: if you parse the HTML once - on the first request - you can
easily compose - as in composition - a hierarchy of objects that
render the result. You already parse the HTML and creating the
composition should be much easier than generating Java code or
bytecode. It also would be fully dynamic and can be easily
regenerated.
To me the fact that the controller is a POJO is a big big plus since
this means any POJO can be the model/controller, also the return value
of a method invocation. This my friend is the way to go with wedge. Go
boldy where no man has gone before and tie web requests to methods,
kind of like Web Flow does but more direct.
To provide an example of what I mean, say you have a Person object:
public class Person {
private String firstname;
private String lastname;
/* getters and constructor ommitted */
}
And a method that looks up a Person object:
public class PersonMapper {
public Person findPersonById(int id) {
// do stuff to find Person object and return
}
}
You can call the findPersonById() method and bind the 'id' request
parameter to the id argument of the method.
After the method executes you have the POJO to use as your model, and
you don't need form backing objects anymore.
To configure this the XML below suffices, and like Seth says this can
be a Spring 2.0 custom schema:
<wedge:request uri=3D"/personDetail"
method=3D"personMapperBean.findPersonById(id)"/>
This would make wedge a very cool framework in my opinion, one that's
ready for the future.
> > Unfortunately I do not see how I can make the wedge framework to work
> > without any kind of information source.
>
> I know you can do it. :) If anything, don't introduce Yet Another XML
> File. Use Spring 2.0's new XML Schema aware XML files. You can write
> your own namespace handlers, and thus it's like you are making your
> own XML file, yet you get to use all of the Spring XML definition
> framework.
>
> Seth
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
--
Steven Devijver
Senior Consultant
Interface21
Spring Services from the Source
http://www.interface21.com
Co-author, "Expert Spring MVC and Web Flow"
(February 2006, with Seth Ladd, Darren Davison, and Colin Yates)
http://www.amazon.com/gp/product/159059584X
Interface21 NL B.V.
Donker Curtiusstraat 7-400c
1051JL Amsterdam
The Netherlands
Phone: +31 (0)20 486 47 63
Fax: +31 (0)20 475 08 28
Mail: st...@in...
Skype: devijvers
|