tiny java web framework

[Arved Sandstrom]

Arne Vajhøj wrote:
[ SNIP ]

There has been a lot of criticism of Struts and JSF for being
to "heavy" (which is not a very welldefined term - is is number
of files in solution, size of API or just the presence of XML
config files?).

[ SNIP ]

I've read those criticisms too, and as far as JSF is concerned I have no
idea why people think it's "heavy". Who cares about how many classes are
actually in the API and in a typical implementation? More to the point
is what you actually need to master and use to get a typical
high-quality web application written, and in that sense JSF is quite
lightweight.

Having all those UI components is not heavyweight - they translate very
closely to HTML and often save labour.

The JSF lifecycle isn't bad - I suspect most people who complain about
it haven't taken the time to become very familiar with it.

If you have a problem with default forwarding by the Faces servlet,
specify <redirect/>. How tough is that? If you stick with forward, and
the browser can't find some resources for the new page (images etc),
then specify your HREFs correctly by using the context as well. How
tough is that?

Number of files you have to write yourself - when all is said and done
there aren't more than what you reasonably need. I don't care what
framework you use, you have to put logic somewhere, and JSF allows one
to organize this logic quite well.

XML config files - OK, I'll grant this can be a bit painful. But it's
always been relatively easy to write one's own navigation handler so
that you can dispense with navigation rules in faces-config.xml and
directly return views from action methods. As for specifying managed
beans, JSF 2.0 takes care of that problem with annotations.

I have to admit my view is coloured by using Facelets, as opposed to
JSPs. It's also influenced by the fact that I don't have to stick with
core JSF tags but have powerful 3rd party component libraries like
ICEFaces available.

AHS

 

[Donkey Hottie]

I'm looking for zero-stack, zero-overhead, no ORM, no
templates, no MVC web framework for java. Suggestions?

Check out Brazil.

http://java-source.net/open-source/web-servers/brazil

I looked about it years ago and it felt interesting. Never did anything with
it, though.

 

[Donkey Hottie]

Check out Brazil.

http://java-source.net/open-source/web-servers/brazil

I looked about it years ago and it felt interesting.
Never did anything with it, though.

Never mind.

The original Sun Brazil was a tiny web application server meant for fridges,
microwave ovens and similar, but this current is not the same, or has
evolved to a different direction..

 

[Alessio Stalla]

Arne Vajhøj wrote:

[ SNIP ]

There has been a lot of criticism of Struts and JSF for being
to "heavy" (which is not a very welldefined term - is is number
of files in solution, size of API or just the presence of XML
config files?).

[ SNIP ]

I've read those criticisms too, and as far as JSF is concerned I have no
idea why people think it's "heavy". Who cares about how many classes are
actually in the API and in a typical implementation? More to the point
is what you actually need to master and use to get a typical
high-quality web application written, and in that sense JSF is quite
lightweight.

Having all those UI components is not heavyweight - they translate very
closely to HTML and often save labour.

The JSF lifecycle isn't bad - I suspect most people who complain about
it haven't taken the time to become very familiar with it.

If you have a problem with default forwarding by the Faces servlet,
specify <redirect/>. How tough is that? If you stick with forward, and
the browser can't find some resources for the new page (images etc),
then specify your HREFs correctly by using the context as well. How
tough is that?

Number of files you have to write yourself - when all is said and done
there aren't more than what you reasonably need. I don't care what
framework you use, you have to put logic somewhere, and JSF allows one
to organize this logic quite well.

XML config files - OK, I'll grant this can be a bit painful. But it's
always been relatively easy to write one's own navigation handler so
that you can dispense with navigation rules in faces-config.xml and
directly return views from action methods. As for specifying managed
beans, JSF 2.0 takes care of that problem with annotations.

I have to admit my view is coloured by using Facelets, as opposed to
JSPs. It's also influenced by the fact that I don't have to stick with
core JSF tags but have powerful 3rd party component libraries like
ICEFaces available.

AHS

I have been working on web applications using JSF (ICEFaces) for more
than a year. To me, the big problem of JSF is not that it's "heavy" -
but that it has a number of shortcomings which at best can be avoided
with ugly hacks, if they can be avoided at all. Some examples:

- Single field validation, and NO way to have application-level
validation working exactly like built-in validation
- The strict MVC policy of not propagating values to the model if
there are validation errors, while theoretically "right", poses a
number of problems, and the immediate="true" hack does not make things
much better
- Writing components which are composed of other components is a pain,
and
- writing component trees programmatically (as opposed to JSP/
Facelets) is a pain, because
- JSF components do not respect basic OO principles like, if you have
a method common to ALL components put it to the base class instead of
redefining it for each and every component;
- however, writing component trees programmatically is the ONLY way to
have a true loop in the component tree (like foreach in jstl), since
basic JSF has nothing like that and ICEFaces has only panelSeries
which is not quite the same thing

and more... JSF has convinced me that building something on top of
HTTP and pretending HTTP doesn't exist is a bad, bad idea. I hope JSF
2.0 will be better, but I'm not very optimistic...

Alessio

 

[Arved Sandstrom]

On Jul 9, 3:18 am, Arved Sandstrom <[email protected]> wrote:

[ SNIP ]

I have been working on web applications using JSF (ICEFaces) for more
than a year. To me, the big problem of JSF is not that it's "heavy" -
but that it has a number of shortcomings which at best can be avoided
with ugly hacks, if they can be avoided at all. Some examples:

- Single field validation, and NO way to have application-level
validation working exactly like built-in validation

I understand what you're saying. My approach here is to accept the JSF
validation for what it is (field-level validation), and keep the
application-level validation in the business logic. After all,
application-level validation consists of business rules.

You can certainly make the result appear the same by creating an
appropriate FacesMessage in the backing bean if the business logic
application-level validation reports a problem. In effect this is the
same thing as the built-in for field-level validation. It's not much
extra work.

- The strict MVC policy of not propagating values to the model if
there are validation errors, while theoretically "right", poses a
number of problems, and the immediate="true" hack does not make things
much better

What do you consider the problems to be? If after specifying what's
required and what's not, if some of the required fields are not
validating what else would you wish to do other than have the user fix
the inputs?

As for immediate="true", that's not a hack. You use it when you identify
a scenario on a page where validation is not necessary. As an example
you might have a login page with form fields for username and password,
that validate when you click a Login button, and a link for registration
as a new user. You wouldn't expect the registration commandLink to
require validation on the inputText and inputSecret.

- Writing components which are composed of other components is a pain,
and
- writing component trees programmatically (as opposed to JSP/
Facelets) is a pain, because
- JSF components do not respect basic OO principles like, if you have
a method common to ALL components put it to the base class instead of
redefining it for each and every component;
- however, writing component trees programmatically is the ONLY way to
have a true loop in the component tree (like foreach in jstl), since
basic JSF has nothing like that and ICEFaces has only panelSeries
which is not quite the same thing

I can't even comment on writing components programmatically. I have
never had to do it, and don't intend to start. I stick to Facelets.

and more... JSF has convinced me that building something on top of
HTTP and pretending HTTP doesn't exist is a bad, bad idea. I hope JSF
2.0 will be better, but I'm not very optimistic...

Alessio

I'm not 100% on what you mean here. Are you alluding to the fact that as
compared to raw servlets you tend not to think about the request and
response objects so much in JSF?

I'm probably not the best person to get into a long discussion with
about JSF deficiencies. At work I rarely have much of a choice as to
whether it's going to be J2EE with JSF, or J2EE with Spring, let alone
the app server or database for that matter, or whether it's ASP.NET MVC
with C# or HTML with ActiveX, or C++ for a command line toolchain, or VB
doing processing with XSLT...you get the drift. Those choices are
largely driven by existing client infrastructure and high-level
uninformed managerial choices. So I just settle in and use whatever I
have to use, figure out what I cannot do and what the workarounds are,
and then don't even worry about it.

IOW, I could truly hate JSF but I'd still have to use it.

AHS

 

[Alessio Stalla]

On Jul 9, 3:18 am, Arved Sandstrom <[email protected]> wrote:

[ SNIP ]

I have been working on web applications using JSF (ICEFaces) for more
than a year. To me, the big problem of JSF is not that it's "heavy" -
but that it has a number of shortcomings which at best can be avoided
with ugly hacks, if they can be avoided at all. Some examples:

- Single field validation, and NO way to have application-level
validation working exactly like built-in validation

I understand what you're saying. My approach here is to accept the JSF
validation for what it is (field-level validation), and keep the
application-level validation in the business logic. After all,
application-level validation consists of business rules.

You can certainly make the result appear the same by creating an
appropriate FacesMessage in the backing bean if the business logic
application-level validation reports a problem. In effect this is the
same thing as the built-in for field-level validation. It's not much
extra work.

Yes, but it does not behave the same - in one case the model gets
updated, in the other it doesn't. Having a mix of the two is a pain,
so in the end for complex validation you are basically forced to avoid
built-in validation entirely.

What do you consider the problems to be? If after specifying what's
required and what's not, if some of the required fields are not
validating what else would you wish to do other than have the user fix
the inputs?

As for immediate="true", that's not a hack. You use it when you identify
a scenario on a page where validation is not necessary. As an example
you might have a login page with form fields for username and password,
that validate when you click a Login button, and a link for registration
as a new user. You wouldn't expect the registration commandLink to
require validation on the inputText and inputSecret.

I refer to this scenario (among others):

1. user inputs some data, some of which is invalid, and does a
postback
2. user performs some immediate="true" action that needs to reset the
model somehow and have the GUI reflect that (typically cleaning the
form)
3. the effect is that the model is reset, but the GUI still reflects
the old values, unless you manually iterate over the component tree
emptying values programmatically.

I can't even comment on writing components programmatically. I have
never had to do it, and don't intend to start. I stick to Facelets.

Unfortunately I had to do it... the end result is nice and powerful,
but arriving to it has been a pain, and thankfully I use Facelets
because with JSP the pain would have been doubled

I'm not 100% on what you mean here. Are you alluding to the fact that as
compared to raw servlets you tend not to think about the request and
response objects so much in JSF?

Yes, I mean that the usual request-response cycle is somehow
subverted, and the usual linear flow you have in JSPs is absent (since
you no longer write output but build a component tree instead). You
are supposed to have benefits in return, but I haven't seen many.
Maybe I've just been unlucky, or I haven't understood the true power
of JSF.

I'm probably not the best person to get into a long discussion with
about JSF deficiencies. At work I rarely have much of a choice as to
whether it's going to be J2EE with JSF, or J2EE with Spring, let alone
the app server or database for that matter, or whether it's ASP.NET MVC
with C# or HTML with ActiveX, or C++ for a command line toolchain, or VB
doing processing with XSLT...you get the drift. Those choices are
largely driven by existing client infrastructure and high-level
uninformed managerial choices. So I just settle in and use whatever I
have to use, figure out what I cannot do and what the workarounds are,
and then don't even worry about it.

IOW, I could truly hate JSF but I'd still have to use it.

Ok, then we agree completely

Ale

 

[Kent]

I'm looking for zero-stack, zero-overhead, no ORM, no templates, no
MVC web framework for java. Suggestions?

actually if you wanna a super-lightweight MVC framework, I thought
your project is not heavy either, then you could build the MVC by
yourself. make a frontcontroller handle authentication, session etc,
and a controller processing those requests, split/forward them to
"Actions". also the controller will choose the jsp page to represent
the result after the Action return the value.

 

[Lew]

actually if you wanna a super-lightweight MVC framework, I thought

Well, for some peculiar reason the OP did state "no MVC". That was their
mistake, of course.

your project is not heavy either, then you could build the MVC by
yourself. make a frontcontroller handle authentication, session etc,
and a controller processing those requests, split/forward them to
"Actions". also the controller will choose the jsp page to represent
the result after the Action return the value.

I've rolled a number of apps such as you describe. It's not difficult (look
up "Model 2" apps on java.sun.com). It is amazing how quickly you come to
appreciate the frameworks when you've coped with the issues manually for a while.

 

[Arved Sandstrom]

On Jul 9, 3:18 am, Arved Sandstrom <[email protected]> wrote:

[ SNIP ]

I have been working on web applications using JSF (ICEFaces) for more
than a year. To me, the big problem of JSF is not that it's "heavy" -
but that it has a number of shortcomings which at best can be avoided
with ugly hacks, if they can be avoided at all. Some examples:
- Single field validation, and NO way to have application-level
validation working exactly like built-in validation

I understand what you're saying. My approach here is to accept the JSF
validation for what it is (field-level validation), and keep the
application-level validation in the business logic. After all,
application-level validation consists of business rules.

You can certainly make the result appear the same by creating an
appropriate FacesMessage in the backing bean if the business logic
application-level validation reports a problem. In effect this is the
same thing as the built-in for field-level validation. It's not much
extra work.

Yes, but it does not behave the same - in one case the model gets
updated, in the other it doesn't. Having a mix of the two is a pain,
so in the end for complex validation you are basically forced to avoid
built-in validation entirely.

I agree, obviously; if you get past built-in you've updated the model.
For me that's just something to take into account, because I interpret
an updated model as simply being the result of a successful form submit
(postback). As I said, I consider application-level validation to be
business logic, so posting an application validation failure message if
rendering the same view is conceptually no different to me than taking
any other business action (for example, staying on the same page after
doing some intermediate computations upon a form submit).

I refer to this scenario (among others):

1. user inputs some data, some of which is invalid, and does a
postback
2. user performs some immediate="true" action that needs to reset the
model somehow and have the GUI reflect that (typically cleaning the
form)
3. the effect is that the model is reset, but the GUI still reflects
the old values, unless you manually iterate over the component tree
emptying values programmatically.

This is one of the situations that gets cited most often. There are, as
you know, tried and true approaches, and MyFaces Wiki has a good page on
them (http://wiki.apache.org/myfaces/ClearInputComponents). You've
referenced one of these approaches.

I've typically found one or the other of these techniques to work out
OK. Also, a reset doesn't always mean clearing component values - I
frequently have to implement resets that restore certain other values -
so one size doesn't fit all.

[ SNIP ]

Yes, I mean that the usual request-response cycle is somehow
subverted, and the usual linear flow you have in JSPs is absent (since
you no longer write output but build a component tree instead). You
are supposed to have benefits in return, but I haven't seen many.
Maybe I've just been unlucky, or I haven't understood the true power
of JSF.

[ SNIP ]

The way I look at it is, I'm still writing the output. I've created the
view structure, and I write to the values that are used to populate that
view.

I don't see that the linearity has gone away either. With a servlet I
get the request, and it's my job to write to the response, and
everything in between is up to me, starting with pulling out request
values. All JSF has done for forms, boiled down, is keep the servlet
(although we don't directly use it), and do the grunt work of doing
useful things with the request values.

If you were to create an MVC architecture from scratch, starting with a
servlet, this is one of the main models that you would inexorably be
drawn towards. It's perhaps not so immediately apparent because we
usually code in the view layer, in the business logic or data access
layer, and supply navigation information from the outside
(faces-config.xml or otherwise), but this is still a very linear "get
the request - do something - write the response" model.

AHS

 

[Arne Vajhøj]

actually if you wanna a super-lightweight MVC framework, I thought
your project is not heavy either, then you could build the MVC by
yourself. make a frontcontroller handle authentication, session etc,
and a controller processing those requests, split/forward them to
"Actions". also the controller will choose the jsp page to represent
the result after the Action return the value.

I think that would be reinventing the wheel.

Arne