Re: Looking For Direction
 

On Jun 9, 11:19*pm, "JC" <jjcarde...@hotmail.com> wrote:
> For the user interface I am thinking of something that is
> integrated with a web browser.

In addition to what everyone else said, I'd like to concentrate on
this point. Are you really sure you need a web-based interface (i.e.,
do you really need to expose your application to potentially anyone
anywhere), or are you considering it just because it's today's trend
to build web applications?

In my experience (2+ years in JSF + some minor projects with Struts)
web applications often face an additional layer of complexity than
client-server applications, and are generally limited in functionality
(by the browser and by the stateless nature of the HTTP protocol).

I think JSF especially is a very bad choice. I used the ICEFaces
implementation, which adds its own host of problems, but JSF in
general is terribly complex, and has a fundamentally bad design.
Imagine someone proposed to you, for a client-server application:
"hey, let's do this cool thing, let's keep *all* the GUI state on the
server and ask for it *each and every time* the user interacts with
the GUI"... you would say that's crazy, wouldn't you? Yet it's
precisely what JSF does (and ICEFaces exacerbates the problem by
forcing everything to be AJAX, even stuff that could be client-side
only, like help tooltips). Then, there's the complex and strict life
cycle, the macroscopic mistakes in the class hierarchy, and I could go
on and on...

So, I'd suggest you to use Swing + Java Web Start (JNLP) + Spring HTTP
remoting to communicate with the server.

If you really, really *need* a browser, consider GWT. It makes you
write a JavaScript GUI... without JavaScript, using Java. Not as
powerful as a client-server app, but relatively close.

hth,
Alessio

Re: Looking For Direction
 

On 10-06-2010 11:03, Alessio Stalla wrote:
> On Jun 9, 11:19 pm, "JC"<jjcarde...@hotmail.com> wrote:
>> For the user interface I am thinking of something that is
>> integrated with a web browser.
>
> In addition to what everyone else said, I'd like to concentrate on
> this point. Are you really sure you need a web-based interface (i.e.,
> do you really need to expose your application to potentially anyone
> anywhere), or are you considering it just because it's today's trend
> to build web applications?
>
> In my experience (2+ years in JSF + some minor projects with Struts)
> web applications often face an additional layer of complexity than
> client-server applications, and are generally limited in functionality
> (by the browser and by the stateless nature of the HTTP protocol).
>
> I think JSF especially is a very bad choice. I used the ICEFaces
> implementation, which adds its own host of problems, but JSF in
> general is terribly complex, and has a fundamentally bad design.
> Imagine someone proposed to you, for a client-server application:
> "hey, let's do this cool thing, let's keep *all* the GUI state on the
> server and ask for it *each and every time* the user interacts with
> the GUI"... you would say that's crazy, wouldn't you? Yet it's
> precisely what JSF does

That is what all non-AJAXified web apps does.

You can do AJAX with JSF if you want to.

> (and ICEFaces exacerbates the problem by
> forcing everything to be AJAX, even stuff that could be client-side
> only, like help tooltips).

AJAX is by definition running client side.

> Then, there's the complex and strict life
> cycle,

Just learn it.

> the macroscopic mistakes in the class hierarchy,

If we would ditch all API's where someone did not like something,
then there would not be many API's available.

Arne

Re: Looking For Direction
 

On Jun 11, 12:00*am, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 10-06-2010 11:03, Alessio Stalla wrote:
>
>
>
> > On Jun 9, 11:19 pm, "JC"<jjcarde...@hotmail.com> *wrote:
> >> For the user interface I am thinking of something that is
> >> integrated with a web browser.
>
> > In addition to what everyone else said, I'd like to concentrate on
> > this point. Are you really sure you need a web-based interface (i.e.,
> > do you really need to expose your application to potentially anyone
> > anywhere), or are you considering it just because it's today's trend
> > to build web applications?
>
> > In my experience (2+ years in JSF + some minor projects with Struts)
> > web applications often face an additional layer of complexity than
> > client-server applications, and are generally limited in functionality
> > (by the browser and by the stateless nature of the HTTP protocol).
>
> > I think JSF especially is a very bad choice. I used the ICEFaces
> > implementation, which adds its own host of problems, but JSF in
> > general is terribly complex, and has a fundamentally bad design.
> > Imagine someone proposed to you, for a client-server application:
> > "hey, let's do this cool thing, let's keep *all* the GUI state on the
> > server and ask for it *each and every time* the user interacts with
> > the GUI"... you would say that's crazy, wouldn't you? Yet it's
> > precisely what JSF does
>
> That is what all non-AJAXified web apps does.

No. Most web frameworks reconstruct the page for every request, and,
if applications are designed with a bit of cleverness, they only keep
in session the minimum amount of state necessary to reconstruct the
view. They don't keep in memory all the labels, all the CSS classes,
all the component ids, ... like JSF does.

> You can do AJAX with JSF if you want to.

You can, of course. I have only used ICEFaces which does a terrible
job at it, but maybe other AJAX JSF implementations are saner.

>
> > * * * * * * * * * * * * *(and ICEFaces exacerbates the problem by
> > forcing everything to be AJAX, even stuff that could be client-side
> > only, like help tooltips).
>
> AJAX is by definition running client side.

No, AJAX by definition is asking stuff to the server asynchronously.
Why showing a help tooltip, or opening or closing a date selection
popup, should ask the server for data?

> > * * * * * * * * * * * Then, there's the complex and strict life
> > cycle,
>
> Just learn it.

I did learn it. I also endlessly fought against it when it proved to
be too inflexible. How demented it is that to *empty* a form I have to
generate an "immediate" event and cycle through the tree of components
in the view to empty them *by hand*? And that I have to jump through
hoops because "emptying" a component can mean different things for
different components?

> > the macroscopic mistakes in the class hierarchy,
>
> If we would ditch all API's where someone did not like something,
> then there would not be many API's available.

Replicating isDisabled on all components rather than declaring it once
on UIComponent and inheriting it is an objective mistake. And it's not
just isDisabled, other methods are like that. You have to resort to
reflection to do even simple things uniformly for all components.
State saving is also cumbersome and error-prone, but I can live with
that. Creating components programmatically is unnecessarily hard.
Parsing dates by default forcing GMT timezone is wrong. Etc. etc.

Alessio

Re: Looking For Direction
 

Alessio Stalla wrote:
> On Jun 11, 12:00 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
>> On 10-06-2010 11:03, Alessio Stalla wrote:
>>
>>
>>
>>> On Jun 9, 11:19 pm, "JC"<jjcarde...@hotmail.com> wrote:
>>>> For the user interface I am thinking of something that is
>>>> integrated with a web browser.
>>> In addition to what everyone else said, I'd like to concentrate on
>>> this point. Are you really sure you need a web-based interface (i.e.,
>>> do you really need to expose your application to potentially anyone
>>> anywhere), or are you considering it just because it's today's trend
>>> to build web applications?
>>> In my experience (2+ years in JSF + some minor projects with Struts)
>>> web applications often face an additional layer of complexity than
>>> client-server applications, and are generally limited in functionality
>>> (by the browser and by the stateless nature of the HTTP protocol).
>>> I think JSF especially is a very bad choice. I used the ICEFaces
>>> implementation, which adds its own host of problems, but JSF in
>>> general is terribly complex, and has a fundamentally bad design.
>>> Imagine someone proposed to you, for a client-server application:
>>> "hey, let's do this cool thing, let's keep *all* the GUI state on the
>>> server and ask for it *each and every time* the user interacts with
>>> the GUI"... you would say that's crazy, wouldn't you? Yet it's
>>> precisely what JSF does
>> That is what all non-AJAXified web apps does.
>
> No. Most web frameworks reconstruct the page for every request, and,
> if applications are designed with a bit of cleverness, they only keep
> in session the minimum amount of state necessary to reconstruct the
> view. They don't keep in memory all the labels, all the CSS classes,
> all the component ids, ... like JSF does.

That could conceivably become an issue if a _large_ number of
simultaneous (or near-simultaneous) requests caused a large number of
views to be rendered at the same time, sure. On under-performing
hardware and software, moreover.

The scale of the JSF apps I work with is such that there are several
hundred users at any given time, requesting HTML/Javascript/CSS rendered
from fairly complex JSF, _and_ requesting new pages with rather high
frequency besides, and in all normal use that I can recall over the past
few years the servers don't even blink at this particular chore.

The OP knows his own application best. But to me it doesn't sound like
the use of JSF is going to be a problem for him in this regard.

>> You can do AJAX with JSF if you want to.
>
> You can, of course. I have only used ICEFaces which does a terrible
> job at it, but maybe other AJAX JSF implementations are saner.

With all due respect it also depends on how you use ICEFaces. I've used
it a fair bit, and my rule of thumb is to use ICEFaces components only
when I actually need them. Which is not often. I don't use them for
every component on a page, for starters.

To the degree that I have used ICEFaces I myself did _not_ have a
terrible experience. There, that's 2 opposing datapoints.

>>> (and ICEFaces exacerbates the problem by
>>> forcing everything to be AJAX, even stuff that could be client-side
>>> only, like help tooltips).
>> AJAX is by definition running client side.
>
> No, AJAX by definition is asking stuff to the server asynchronously.
> Why showing a help tooltip, or opening or closing a date selection
> popup, should ask the server for data?
>
>>> Then, there's the complex and strict life
>>> cycle,
>> Just learn it.
>
> I did learn it. I also endlessly fought against it when it proved to
> be too inflexible. How demented it is that to *empty* a form I have to
> generate an "immediate" event and cycle through the tree of components
> in the view to empty them *by hand*? And that I have to jump through
> hoops because "emptying" a component can mean different things for
> different components?

Again with all due respect, it sounds to me like you were not working
with JSF - it sounds like you had expectations and pre-conceptions and
they didn't get met. I haven't used a single web framework in any
environment where I didn't have to adapt my thinking to it, rather than
the other way around. Every web framework has had blurbs and
documentation where they claim that they make it easy for the page
author and backing code implementor to write in a natural way - well,
take that with a pound of salt. I haven't used any where that's the
case, and I don't ever expect to.

As for your stated use case, well, I haven't ever - not in several years
of intensively using JSF - ever cleared out a form the way you describe.
I've certainly read blog articles where people discuss doing it that
way, but I've never done it like that. Myself I simply blow away managed
beans if I have to.

>>> the macroscopic mistakes in the class hierarchy,
>> If we would ditch all API's where someone did not like something,
>> then there would not be many API's available.
>
> Replicating isDisabled on all components rather than declaring it once
> on UIComponent and inheriting it is an objective mistake. And it's not
> just isDisabled, other methods are like that. You have to resort to
> reflection to do even simple things uniformly for all components.
> State saving is also cumbersome and error-prone, but I can live with
> that. Creating components programmatically is unnecessarily hard.
> Parsing dates by default forcing GMT timezone is wrong. Etc. etc.
>
> Alessio

I figure everyone's experience is different. I've certainly had issues
with JSF 1.x (and most if not all of them have gotten addressed with JSF
2), but those issues don't exactly sound like yours. Generally speaking
I've found it fairly easy to get the pages I need with JSF, my own
Javascript, and CSS, and the right code in the backing beans, and the
pages I produce are handling some fairly complex busness situations.

If I had any complaints about API shortcomings in J2EE then JSF wouldn't
be tops of the list. It might be #4 or #5 at most. For me it simply
doesn't cause many problems.

AHS
--
It should be noted that no ethically-trained software engineer would
ever consent to write a DestroyBaghdad procedure. Basic professional
ethics would instead require him to write a DestroyCity procedure, to
which Baghdad could be given as a parameter.
-- Nathaniel Borenstein

Re: Looking For Direction
 

On Jun 11, 12:20*pm, Arved Sandstrom <dces...@hotmail.com> wrote:
> Alessio Stalla wrote:
> > On Jun 11, 12:00 am, Arne Vajhøj <a...@vajhoej.dk> wrote:
> >> On 10-06-2010 11:03, Alessio Stalla wrote:
>
> >>> On Jun 9, 11:19 pm, "JC"<jjcarde...@hotmail.com> *wrote:
> >>>> For the user interface I am thinking of something that is
> >>>> integrated with a web browser.
> >>> In addition to what everyone else said, I'd like to concentrate on
> >>> this point. Are you really sure you need a web-based interface (i.e.,
> >>> do you really need to expose your application to potentially anyone
> >>> anywhere), or are you considering it just because it's today's trend
> >>> to build web applications?
> >>> In my experience (2+ years in JSF + some minor projects with Struts)
> >>> web applications often face an additional layer of complexity than
> >>> client-server applications, and are generally limited in functionality
> >>> (by the browser and by the stateless nature of the HTTP protocol).
> >>> I think JSF especially is a very bad choice. I used the ICEFaces
> >>> implementation, which adds its own host of problems, but JSF in
> >>> general is terribly complex, and has a fundamentally bad design.
> >>> Imagine someone proposed to you, for a client-server application:
> >>> "hey, let's do this cool thing, let's keep *all* the GUI state on the
> >>> server and ask for it *each and every time* the user interacts with
> >>> the GUI"... you would say that's crazy, wouldn't you? Yet it's
> >>> precisely what JSF does
> >> That is what all non-AJAXified web apps does.
>
> > No. Most web frameworks reconstruct the page for every request, and,
> > if applications are designed with a bit of cleverness, they only keep
> > in session the minimum amount of state necessary to reconstruct the
> > view. They don't keep in memory all the labels, all the CSS classes,
> > all the component ids, ... like JSF does.
>
> That could conceivably become an issue if a _large_ number of
> simultaneous (or near-simultaneous) requests caused a large number of
> views to be rendered at the same time, sure. On under-performing
> hardware and software, moreover.
>
> The scale of the JSF apps I work with is such that there are several
> hundred users at any given time, requesting HTML/Javascript/CSS rendered
> from fairly complex JSF, _and_ requesting new pages with rather high
> frequency besides, and in all normal use that I can recall over the past
> few years the servers don't even blink at this particular chore.
>
> The OP knows his own application best. But to me it doesn't sound like
> the use of JSF is going to be a problem for him in this regard.

I'm not making a point for efficiency (or lack thereof), but simply
for the unneeded complexity of the approach. Have you ever tried to
write custom components as composition of library components, for
example? A thing that a component-based framework should support and
even encourage, right? Yet it's painfully hard to do.

> >> You can do AJAX with JSF if you want to.
>
> > You can, of course. I have only used ICEFaces which does a terrible
> > job at it, but maybe other AJAX JSF implementations are saner.
>
> With all due respect it also depends on how you use ICEFaces. I've used
> it a fair bit, and my rule of thumb is to use ICEFaces components only
> when I actually need them. Which is not often. I don't use them for
> every component on a page, for starters.

Well, they explicitly don't encourage mixing ICE and non-ICE
components on the page so we never did that.

> To the degree that I have used ICEFaces I myself did _not_ have a
> terrible experience. There, that's 2 opposing datapoints.
>

Sure, mine is just a data point. I'm trying to provide reasons for my
negative opinion, but of course YMMV.

>
> >>> * * * * * * * * * * * * *(and ICEFaces exacerbates the problem by
> >>> forcing everything to be AJAX, even stuff that could be client-side
> >>> only, like help tooltips).
> >> AJAX is by definition running client side.
>
> > No, AJAX by definition is asking stuff to the server asynchronously.
> > Why showing a help tooltip, or opening or closing a date selection
> > popup, should ask the server for data?
>
> >>> * * * * * * * * * * * Then, there's the complex and strict life
> >>> cycle,
> >> Just learn it.
>
> > I did learn it. I also endlessly fought against it when it proved to
> > be too inflexible. How demented it is that to *empty* a form I have to
> > generate an "immediate" event and cycle through the tree of components
> > in the view to empty them *by hand*? And that I have to jump through
> > hoops because "emptying" a component can mean different things for
> > different components?
>
> Again with all due respect, it sounds to me like you were not working
> with JSF - it sounds like you had expectations and pre-conceptions and
> they didn't get met. I haven't used a single web framework in any
> environment where I didn't have to adapt my thinking to it, rather than
> the other way around. Every web framework has had blurbs and
> documentation where they claim that they make it easy for the page
> author and backing code implementor to write in a natural way - well,
> take that with a pound of salt. I haven't used any where that's the
> case, and I don't ever expect to.

I don't expect the silver bullet that will easily solve all problems.
However, I expect a framework to not make things harder than they
normally are.

> As for your stated use case, well, I haven't ever - not in several years
> of intensively using JSF - ever cleared out a form the way you describe.
> I've certainly read blog articles where people discuss doing it that
> way, but I've never done it like that. Myself I simply blow away managed
> beans if I have to.

Blowing away managed beans is not enough to make components reload the
value from the model if the clear action was immediate. And it has to
be immediate if you want to skip validation, and you do want to skip
it - preventing a form to be cleared because it has validation errors
is silly, isn't it? So you have to .setValue(null) on all the
components. Except that for some it's .setSubmittedValue(null)
instead. And guess what, it's not documented anywhere and you have to
discover it the hard way, by trial and error.

And then, any events, not just form posts, go through the whole life
cycle. You open the calendar popup of the date input component? The
form gets validated. The value typed in an autocompleter changes...
the form gets validated. Ugh.

> >>> the macroscopic mistakes in the class hierarchy,
> >> If we would ditch all API's where someone did not like something,
> >> then there would not be many API's available.
>
> > Replicating isDisabled on all components rather than declaring it once
> > on UIComponent and inheriting it is an objective mistake. And it's not
> > just isDisabled, other methods are like that. You have to resort to
> > reflection to do even simple things uniformly for all components.
> > State saving is also cumbersome and error-prone, but I can live with
> > that. Creating components programmatically is unnecessarily hard.
> > Parsing dates by default forcing GMT timezone is wrong. Etc. etc.
>
> > Alessio
>
> I figure everyone's experience is different. I've certainly had issues
> with JSF 1.x (and most if not all of them have gotten addressed with JSF
> 2), but those issues don't exactly sound like yours. Generally speaking
> I've found it fairly easy to get the pages I need with JSF, my own
> Javascript, and CSS, and the right code in the backing beans, and the
> pages I produce are handling some fairly complex busness situations.
>
> If I had any complaints about API shortcomings in J2EE then JSF wouldn't
> be tops of the list. It might be #4 or #5 at most. For me it simply
> doesn't cause many problems.

Well, we didn't use J2EE APIs a lot; besides JSF 1.2, we only used
some little JMS and JPA annotations. So, maybe JSF is not the worst
part of J2EE; I sincerely hope it is, though ;)

Alessio