Re: Looking For Direction

Discussion in 'Java' started by Alessio Stalla, Jun 10, 2010.

  1. On Jun 9, 11:19 pm, "JC" <> 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
    Alessio Stalla, Jun 10, 2010
    #1
    1. Advertising

  2. Alessio Stalla

    Arne Vajhøj Guest

    On 10-06-2010 11:03, Alessio Stalla wrote:
    > On Jun 9, 11:19 pm, "JC"<> 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
    Arne Vajhøj, Jun 10, 2010
    #2
    1. Advertising

  3. On Jun 11, 12:00 am, Arne Vajhøj <> wrote:
    > On 10-06-2010 11:03, Alessio Stalla wrote:
    >
    >
    >
    > > On Jun 9, 11:19 pm, "JC"<>  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
    Alessio Stalla, Jun 11, 2010
    #3
  4. Alessio Stalla wrote:
    > On Jun 11, 12:00 am, Arne Vajhøj <> wrote:
    >> On 10-06-2010 11:03, Alessio Stalla wrote:
    >>
    >>
    >>
    >>> On Jun 9, 11:19 pm, "JC"<> 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
    Arved Sandstrom, Jun 11, 2010
    #4
  5. On Jun 11, 12:20 pm, Arved Sandstrom <> wrote:
    > Alessio Stalla wrote:
    > > On Jun 11, 12:00 am, Arne Vajhøj <> wrote:
    > >> On 10-06-2010 11:03, Alessio Stalla wrote:

    >
    > >>> On Jun 9, 11:19 pm, "JC"<>  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
    Alessio Stalla, Jun 11, 2010
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Tero Kapanen

    Slicing of an array: wrong direction

    Tero Kapanen, Nov 4, 2003, in forum: VHDL
    Replies:
    11
    Views:
    7,236
    Allan Herriman
    Nov 7, 2003
  2. Jeremy Seago

    Looking for a direction

    Jeremy Seago, Sep 13, 2004, in forum: C++
    Replies:
    4
    Views:
    399
    Ioannis Vranos
    Sep 14, 2004
  3. Arne Vajhøj

    Re: Looking For Direction

    Arne Vajhøj, Jun 10, 2010, in forum: Java
    Replies:
    9
    Views:
    299
    Arne Vajhøj
    Jun 10, 2010
  4. Arved Sandstrom

    Re: Looking For Direction

    Arved Sandstrom, Jun 10, 2010, in forum: Java
    Replies:
    33
    Views:
    875
    Arne Vajhøj
    Jun 15, 2010
  5. Thomas Kellerer

    Re: Looking For Direction

    Thomas Kellerer, Jun 11, 2010, in forum: Java
    Replies:
    2
    Views:
    270
    Arne Vajhøj
    Jun 17, 2010
Loading...

Share This Page