Loading ...
Sorry, an error occurred while loading the content.

Re: [java_web_alignment] Goals

Expand Messages
  • Kito D. Mann
    ... That s not an accurate analogy. EJB 2.0 isn t out yet. JSF is out now, and so is Tapestry, Wicket, Echo, Millstone, and other component-based frameworks.
    Message 1 of 22 , Nov 2, 2005
    • 0 Attachment
      >
      > --- "Kito D. Mann" <kmann@...> wrote:
      > >
      > > One last point. I don't think everyone realizes the
      > > magnitude of having a
      > > true UI component model for Java web applications.
      > > The amount of
      > > productivity you can get from having a set of
      > > re-usable components is huge,
      > > and JSF components are starting to gain some
      > > traction. If we can provide
      > > support within other frameworks, I guarantee you component-oriented
      > > Java-oriented web development (with _and_ without
      > > AJAX) will take off. And I
      > > don't think that supporting JSF UI components
      > > necessarily means avoiding a
      > > request/response programming model.
      > >
      > > Thoughts?
      >
      > But saying the JSF UIComponents is the standard is
      > like saying EJB 2.0 is 'the' way to handle
      > persistence. To create a global commodity for
      > component/presentation frameworks, you almost need a super
      > interface that is much simpler to interact with such that
      > tapestry or wicket could define fragmented views alongside
      > JSF components. Again, taking lead from portlets.

      That's not an accurate analogy. EJB 2.0 isn't out yet. JSF is out now, and
      so is Tapestry, Wicket, Echo, Millstone, and other component-based
      frameworks. But if you look at the marketplace, JSF actually has the largest
      number of off-the-shelf components, and it's the only one that has actually
      attracted vendor interest. And, it is technically a standard.

      So, even if the JSF component model evolves into something else, it makes
      sense to capitalize on the marketplace that's already growing.


      > Then we rely on compositions such that traditional MVC
      > JSP views can be maintained as singular component with
      > the same degree of controller interaction as a full
      > blown JSF component. Really, if you look at JSF's
      > UIComponent and pull out a super interface with only
      > the processXXX methods on it, then you've separated
      > out the controller aspect of component interaction--
      > same as portlet's actions.
      >
      > The rest of the stateful component overhead is
      > coordinated within the ViewHandler. If you want to go
      > stateless in your presentation layer, then you go with an
      > alternate ViewHandler for Velocity or JSP.

      The idea of having compositional, stateless components, makes plenty of
      sense to me. It's sort of a different type of beast, though -- sort of like
      ASP.NET's User Controls. From what I can tell, RIFE does this quite well
      (Geert, please correct me if I'm wrong).

      > I'm sure a lot of you are hesitant about JSF, but the
      > pieces are there. They aren't perfect, but the
      > opportunity has already been proven with struts-faces,
      > shale, and seam. I'm sure continuations could be
      > thrown into the mix too. We just resolve the
      > UIComponent lock-in and now you can basically take any
      > framework out there and model/integrate it into JSF as they stand now.

      I actually think the component side of things is more important than the
      basic controller side of things.

      >
      > The reason why I've been looking for framework support
      > with other component models is there's lots of
      > opportunity to take JSF's component implementation
      > into the EJB 3.0 realm of advancement. So this
      > group's goals aside, if JSF is able to peel itself
      > away from direct UIComponent interface interation,
      > then there's a whole other level of possibilities to
      > increase the longevity of the framework or more
      > literally, the 'platform'....

      Can you elaborate? You're not talking about tying it directly to EJB 3.0,
      are you?

      - Kito
    • Kito D. Mann
      So, does anyone else have any comments on these goals? Am I totally off base?
      Message 2 of 22 , Nov 2, 2005
      • 0 Attachment
        So, does anyone else have any comments on these goals? Am I totally off
        base?

        > -----Original Message-----
        > From: java_web_alignment@yahoogroups.com
        > [mailto:java_web_alignment@yahoogroups.com] On Behalf Of Kito D. Mann
        > Sent: Friday, October 28, 2005 8:44 PM
        > To: java_web_alignment@yahoogroups.com
        > Subject: [java_web_alignment] Goals
        >
        >
        > Hello everyone,
        >
        > First of all, I want to thank everyone for joining this
        > group. I had been thinking of starting it for a while, and
        > after talking to Geert and Patrick at conferences in the past
        > couple of months, I finally did it. So far, there are 36 members.
        >
        > First, let's examine the description of this group:
        >
        > "The Java web framework landscape has become quite
        > fragmented; the purpose of this group is to explore synergies
        > among the existing frameworks that will make life easier for
        > companies, organizations, and developers using Java to build
        > web applications."
        >
        > This is admittedly vague, but the key point is this: the
        > market place is too fragmented (I like choice, but 50 choices
        > is too many, even if only 10 of them are any good), and this
        > fragmentation causes problems such as difficulty in skills
        > transfer between frameworks, confusion at the management and
        > entry level, and higher costs for developers of UI
        > components, IDE plugins, and other high-productivity tools.
        > Anything we can do to address these issues would be a Good Thing.
        >
        > Now that some people have become quite vocal (still a small
        > percentage, I should point out) and I have a sense of
        > people's thoughts, I'd like to take my second stab at stating
        > some possible goals (the first stab is at
        > http://groups.yahoo.com/group/java_web_alignment/message/31).
        >
        > (1) Identify common elements (patterns, practices, and
        > metaphors) and across some of our web frameworks. Come up
        > with a common vocabulary for these elements.
        > - Possible elements include: user interface components,
        > components (in general), Action controllers, continuations,
        > AJAX support, domain integration, Dependency Injection support, etc.
        > - Ted's use-cases suggestion might be a good way to start
        > this process.
        >
        > (2) For some elements, either choose an existing
        > implementation (such as JSF components, EL, or RIFE
        > continuation support) or build a new one
        > - Allow interaction at the API level
        > - Allow interaction at the tool level
        > - In places where we can't agree upon an implementation,
        > provide a pluggable wrapper
        >
        > (3) Provide support among different frameworks for these elements
        >
        > (4) Consider merging some frameworks (i.e. Clarity)
        >
        > (5) Develop a comparison matrix and/or site to help educate
        > people about the different frameworks
        > - Also provide information that might _diminish_ the desire
        > of others to create frameworks that duplicate existing
        > functionality (and don't provide added value). This info
        > might include common elements that can be used in new and
        > existing frameworks.
        >
        > (6) Evaluate ways we can make all of our frameworks more
        > agile and competitive with offerings such as Ruby on Rails or ASP.NET
        >
        > I'd like to officially punt on the following concepts (I
        > think this is the general consensus, as well):
        >
        > - Worrying about other platforms (.NET, PHP, Ruby, etc.). If
        > anything great comes out of this group, then it will be
        > ported if there's a need. We should, however, strive for
        > solutions that are elegant enough for people to _want_ to port them.
        >
        > - Creating an uber-framework. If a new framework emerges (or
        > if Clarity grows or changes due to this group), that's great.
        > I think it's safer to focus on smaller goals, like just
        > making things work together where possible.
        >
        > - Turning this into a JSR. It's too early to do anything
        > formal with this group; I'd prefer that we try and *do*
        > something first :-).
        >
        > One last point. I don't think everyone realizes the magnitude
        > of having a true UI component model for Java web
        > applications. The amount of productivity you can get from
        > having a set of re-usable components is huge, and JSF
        > components are starting to gain some traction. If we can
        > provide support within other frameworks, I guarantee you
        > component-oriented Java-oriented web development (with _and_
        > without AJAX) will take off. And I don't think that
        > supporting JSF UI components necessarily means avoiding a
        > request/response programming model.
        >
        > Thoughts?
        >
        > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        > Kito D. Mann (kmann@...)
        > Principal Consultant, Virtua, Inc. (http://www.virtua.com)
        > Author, JavaServer Faces in Action
        > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
        > phone: 203-323-1244 fax: 203-323-2363
        >
      • Seth Ladd
        ... Personally, I m really behind (1) and (6). (1) is like what aopalliance did, by defining a common set of interfaces, allowing different AOP
        Message 3 of 22 , Nov 2, 2005
        • 0 Attachment
          On 11/2/05, Kito D. Mann <kmann@...> wrote:
          > So, does anyone else have any comments on these goals? Am I totally off
          > base?

          Personally, I'm really behind (1) and (6). (1) is like what
          aopalliance did, by defining a common set of interfaces, allowing
          different AOP implementations. While they are very different, there's
          still some commonality and shared lexicon. I'd basically like to see
          the abstraction for building web apps moved up a level, from request
          and response parameters to something closer to the business logic.

          (6) is _very_ important to me, but I'm not sure it's within the scope
          of this group. (6) to me is basically removing the need for the .war
          generation and deployment. While Java needs the ability to
          edit-in-place for web apps [1], I'm not sure that's our primary focus.

          Seth

          [1] I still believe that the fact that we need to deploy anything at
          all is the number one stumbling block to writing Java web
          applications.
        • jacob hookom
          I would really like to hear about other approaches to component development-- sounds like Rife has a different approach, along with WebWork. There s probably
          Message 4 of 22 , Nov 2, 2005
          • 0 Attachment
            I would really like to hear about other approaches to
            component development-- sounds like Rife has a
            different approach, along with WebWork.

            There's probably opportunity to look at other ways of
            handling components, or starting to take evolutionary
            steps that are more in line with the EJB 2.0 to 3.0
            modifications (an example). JSF focuses around an
            abstract class, UIComponent, with about 35 methods on
            it as it relates to controller interactions, it
            doesn't leave much breathing room/separation for other
            ideas.


            --- "Kito D. Mann" <kmann@...> wrote:

            > >
            > > --- "Kito D. Mann" <kmann@...> wrote:
            > > >
            > > > One last point. I don't think everyone realizes
            > the
            > > > magnitude of having a
            > > > true UI component model for Java web
            > applications.
            > > > The amount of
            > > > productivity you can get from having a set of
            > > > re-usable components is huge,
            > > > and JSF components are starting to gain some
            > > > traction. If we can provide
            > > > support within other frameworks, I guarantee you
            > component-oriented
            > > > Java-oriented web development (with _and_
            > without
            > > > AJAX) will take off. And I
            > > > don't think that supporting JSF UI components
            > > > necessarily means avoiding a
            > > > request/response programming model.
            > > >
            > > > Thoughts?
            > >
            > > But saying the JSF UIComponents is the standard is
            > > like saying EJB 2.0 is 'the' way to handle
            > > persistence. To create a global commodity for
            > > component/presentation frameworks, you almost need
            > a super
            > > interface that is much simpler to interact with
            > such that
            > > tapestry or wicket could define fragmented views
            > alongside
            > > JSF components. Again, taking lead from portlets.
            >
            > That's not an accurate analogy. EJB 2.0 isn't out
            > yet. JSF is out now, and
            > so is Tapestry, Wicket, Echo, Millstone, and other
            > component-based
            > frameworks. But if you look at the marketplace, JSF
            > actually has the largest
            > number of off-the-shelf components, and it's the
            > only one that has actually
            > attracted vendor interest. And, it is technically a
            > standard.
            >
            > So, even if the JSF component model evolves into
            > something else, it makes
            > sense to capitalize on the marketplace that's
            > already growing.
            >
            >
            > > Then we rely on compositions such that traditional
            > MVC
            > > JSP views can be maintained as singular component
            > with
            > > the same degree of controller interaction as a
            > full
            > > blown JSF component. Really, if you look at JSF's
            > > UIComponent and pull out a super interface with
            > only
            > > the processXXX methods on it, then you've
            > separated
            > > out the controller aspect of component
            > interaction--
            > > same as portlet's actions.
            > >
            > > The rest of the stateful component overhead is
            > > coordinated within the ViewHandler. If you want
            > to go
            > > stateless in your presentation layer, then you go
            > with an
            > > alternate ViewHandler for Velocity or JSP.
            >
            > The idea of having compositional, stateless
            > components, makes plenty of
            > sense to me. It's sort of a different type of beast,
            > though -- sort of like
            > ASP.NET's User Controls. From what I can tell, RIFE
            > does this quite well
            > (Geert, please correct me if I'm wrong).
            >
            > > I'm sure a lot of you are hesitant about JSF, but
            > the
            > > pieces are there. They aren't perfect, but the
            > > opportunity has already been proven with
            > struts-faces,
            > > shale, and seam. I'm sure continuations could be
            > > thrown into the mix too. We just resolve the
            > > UIComponent lock-in and now you can basically take
            > any
            > > framework out there and model/integrate it into
            > JSF as they stand now.
            >
            > I actually think the component side of things is
            > more important than the
            > basic controller side of things.
            >
            > >
            > > The reason why I've been looking for framework
            > support
            > > with other component models is there's lots of
            > > opportunity to take JSF's component implementation
            > > into the EJB 3.0 realm of advancement. So this
            > > group's goals aside, if JSF is able to peel itself
            > > away from direct UIComponent interface interation,
            > > then there's a whole other level of possibilities
            > to
            > > increase the longevity of the framework or more
            > > literally, the 'platform'....
            >
            > Can you elaborate? You're not talking about tying it
            > directly to EJB 3.0,
            > are you?
            >
            > - Kito
            >
            >




            __________________________________
            Yahoo! FareChase: Search multiple travel sites in one click.
            http://farechase.yahoo.com
          • Tim Fennell
            Firstly since I m new here, I should probably introduce myself. I m one of those pesky people who had the temerity to publish their own framework recently.
            Message 5 of 22 , Nov 3, 2005
            • 0 Attachment
              Firstly since I'm new here, I should probably introduce myself. I'm
              one of those pesky people who had the temerity to publish their own
              framework recently. If you want to know more about me or it, I'd
              suggest the following as reading:
              http://stripes.mc4j.org (Stripes home page)
              http://jroller.com/page/tfenne/?
              anchor=framework_and_library_usability (Blog entry on framework
              usability)

              Now that that's out of the way... I think there is an unstated goal
              underlying all six goals outlined below. I'm not trying to say we
              can't all see this, but it's important to say it. That goal, to me
              at least, is:
              - Increase the productivity of the whole community doing web
              development in Java

              Am I close? As far as I can tell, all six goals align very nicely to
              that statement. The reason I think this is important is two-fold:
              1. It provides a single way of evaluating trade offs between the
              more granular or tactical goals
              2. It can help keep us focused; it should be a constant where
              other goals may come and go

              My take on the individual goals outlined is as follows:
              1. Identify common elements: a good idea, but only useful if all the
              major players agree to go back and update all their documentation
              (for sure) and code (maybe) to reflect the new terms and
              definitions. Otherwise we end up with a bunch of new/overlapping
              terms and we're no better off than we were before.

              2. Choose of build implementations of some concepts: fantastic idea,
              I'm all for less coding. But at the sharp end, what does it do for
              the user's of our multitude of frameworks? For this to have real
              bite I think we again would need to consider how these
              implementations are integrated into the frameworks, hopefully
              providing identical or near identical interfaces to application
              developers.

              3. See #2.

              4. Consider merging some frameworks: as Patrick has said, and has
              experience with, this is going to be extremely difficult given all
              the egos and user-bases involved. What might be a good next step
              though is to get a lot of smaller framework developers like myself in
              a discussion with some of the big frameworks to find out why we felt
              the need to go building more frameworks. If we can remedy some of
              the causes then we'll be half way there.

              5. Develop a comparison matrix: fantastic idea. But this can't be a
              pissing contest for framework authors, it needs to be a solid
              comparison from a user's perspective. Maybe we could pick a number
              of common development use cases/activities and compare how they would
              be done in each framework?

              6. Evaluate ways we can make all of our frameworks more agile and
              competitive. This is the actually the most important one to me. This
              could be because my main reason for building Stripes was that I felt
              that there wasn't another action-oriented framework that was agile
              enough (that's my opinion, let's not argue about it for now). I just
              wanted a framework that I could use in my work life that was as agile
              and high productivity as it could be. I think if we can focus on
              this across the board, it may well remove a lot of the reasons that
              people go off and build there own frameworks.

              My 2c,

              -t


              On Nov 2, 2005, at 9:26 PM, Kito D. Mann wrote:

              > So, does anyone else have any comments on these goals? Am I totally
              > off
              > base?
              >
              >
              >> -----Original Message-----
              >> From: java_web_alignment@yahoogroups.com
              >> [mailto:java_web_alignment@yahoogroups.com] On Behalf Of Kito D. Mann
              >> Sent: Friday, October 28, 2005 8:44 PM
              >> To: java_web_alignment@yahoogroups.com
              >> Subject: [java_web_alignment] Goals
              >>
              >>
              >> Hello everyone,
              >>
              >> First of all, I want to thank everyone for joining this
              >> group. I had been thinking of starting it for a while, and
              >> after talking to Geert and Patrick at conferences in the past
              >> couple of months, I finally did it. So far, there are 36 members.
              >>
              >> First, let's examine the description of this group:
              >>
              >> "The Java web framework landscape has become quite
              >> fragmented; the purpose of this group is to explore synergies
              >> among the existing frameworks that will make life easier for
              >> companies, organizations, and developers using Java to build
              >> web applications."
              >>
              >> This is admittedly vague, but the key point is this: the
              >> market place is too fragmented (I like choice, but 50 choices
              >> is too many, even if only 10 of them are any good), and this
              >> fragmentation causes problems such as difficulty in skills
              >> transfer between frameworks, confusion at the management and
              >> entry level, and higher costs for developers of UI
              >> components, IDE plugins, and other high-productivity tools.
              >> Anything we can do to address these issues would be a Good Thing.
              >>
              >> Now that some people have become quite vocal (still a small
              >> percentage, I should point out) and I have a sense of
              >> people's thoughts, I'd like to take my second stab at stating
              >> some possible goals (the first stab is at
              >> http://groups.yahoo.com/group/java_web_alignment/message/31).
              >>
              >> (1) Identify common elements (patterns, practices, and
              >> metaphors) and across some of our web frameworks. Come up
              >> with a common vocabulary for these elements.
              >> - Possible elements include: user interface components,
              >> components (in general), Action controllers, continuations,
              >> AJAX support, domain integration, Dependency Injection support, etc.
              >> - Ted's use-cases suggestion might be a good way to start
              >> this process.
              >>
              >> (2) For some elements, either choose an existing
              >> implementation (such as JSF components, EL, or RIFE
              >> continuation support) or build a new one
              >> - Allow interaction at the API level
              >> - Allow interaction at the tool level
              >> - In places where we can't agree upon an implementation,
              >> provide a pluggable wrapper
              >>
              >> (3) Provide support among different frameworks for these elements
              >>
              >> (4) Consider merging some frameworks (i.e. Clarity)
              >>
              >> (5) Develop a comparison matrix and/or site to help educate
              >> people about the different frameworks
              >> - Also provide information that might _diminish_ the desire
              >> of others to create frameworks that duplicate existing
              >> functionality (and don't provide added value). This info
              >> might include common elements that can be used in new and
              >> existing frameworks.
              >>
              >> (6) Evaluate ways we can make all of our frameworks more
              >> agile and competitive with offerings such as Ruby on Rails or ASP.NET
              >>
              >> I'd like to officially punt on the following concepts (I
              >> think this is the general consensus, as well):
              >>
              >> - Worrying about other platforms (.NET, PHP, Ruby, etc.). If
              >> anything great comes out of this group, then it will be
              >> ported if there's a need. We should, however, strive for
              >> solutions that are elegant enough for people to _want_ to port them.
              >>
              >> - Creating an uber-framework. If a new framework emerges (or
              >> if Clarity grows or changes due to this group), that's great.
              >> I think it's safer to focus on smaller goals, like just
              >> making things work together where possible.
              >>
              >> - Turning this into a JSR. It's too early to do anything
              >> formal with this group; I'd prefer that we try and *do*
              >> something first :-).
              >>
              >> One last point. I don't think everyone realizes the magnitude
              >> of having a true UI component model for Java web
              >> applications. The amount of productivity you can get from
              >> having a set of re-usable components is huge, and JSF
              >> components are starting to gain some traction. If we can
              >> provide support within other frameworks, I guarantee you
              >> component-oriented Java-oriented web development (with _and_
              >> without AJAX) will take off. And I don't think that
              >> supporting JSF UI components necessarily means avoiding a
              >> request/response programming model.
              >>
              >> Thoughts?
              >>
              >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
              >> Kito D. Mann (kmann@...)
              >> Principal Consultant, Virtua, Inc. (http://www.virtua.com)
              >> Author, JavaServer Faces in Action
              >> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
              >> phone: 203-323-1244 fax: 203-323-2363
              >>
              >>
              >
              >
              >
              > ------------------------ Yahoo! Groups Sponsor --------------------
              > ~-->
              > Fair play? Video games influencing politics. Click and talk back!
              > http://us.click.yahoo.com/T8sf5C/tzNLAA/TtwFAA/5cFolB/TM
              > --------------------------------------------------------------------
              > ~->
              >
              >
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
              >
            • Ted Husted
              ... For some reason, I stopped getting the JWAG email alerts, and then they started up again today with Tim s message. Weird. Over the weekend, I started a
              Message 6 of 22 , Nov 3, 2005
              • 0 Attachment
                --- In java_web_alignment@yahoogroups.com, "Kito D. Mann" <kmann@v...>
                wrote:
                > - Ted's use-cases suggestion might be a good way to
                > start this process.

                For some reason, I stopped getting the JWAG email alerts, and then
                they started up again today with Tim's message. Weird.

                Over the weekend, I started a home page for Struts Classic Use Cases
                and will build on it as I have time. If anyone else wants to jump in,
                feel free. Jumping in is why Ward invented wikis :)

                * http://opensource.atlassian.com/confluence/oss/x/HQY

                More about Use Cases:

                * http://opensource.atlassian.com/confluence/oss/x/PwM

                -Ted.
              • Kito D. Mann
                ... I m fine with that, as long as we re able to create some sort of bridge which allows existing JSF components to work within any framework that supports the
                Message 7 of 22 , Nov 3, 2005
                • 0 Attachment
                  > -----Original Message-----
                  > From: java_web_alignment@yahoogroups.com
                  > [mailto:java_web_alignment@yahoogroups.com] On Behalf Of jacob hookom
                  > Sent: Wednesday, November 02, 2005 9:52 PM
                  > To: java_web_alignment@yahoogroups.com
                  > Subject: Re: [java_web_alignment] Goals
                  >
                  >
                  > I would really like to hear about other approaches to
                  > component development-- sounds like Rife has a
                  > different approach, along with WebWork.
                  >
                  > There's probably opportunity to look at other ways of
                  > handling components, or starting to take evolutionary
                  > steps that are more in line with the EJB 2.0 to 3.0
                  > modifications (an example). JSF focuses around an abstract
                  > class, UIComponent, with about 35 methods on it as it relates
                  > to controller interactions, it doesn't leave much breathing
                  > room/separation for other ideas.

                  I'm fine with that, as long as we're able to create some sort of bridge
                  which allows existing JSF components to work within any framework that
                  supports the newer model. The rationale is simple: plenty of JSF components
                  already exist, and developers should be able to use them with other
                  frameworks.

                  > --- "Kito D. Mann" <kmann@...> wrote:
                  >
                  > > >
                  > > > --- "Kito D. Mann" <kmann@...> wrote:
                  > > > >
                  > > > > One last point. I don't think everyone realizes
                  > > the
                  > > > > magnitude of having a
                  > > > > true UI component model for Java web
                  > > applications.
                  > > > > The amount of
                  > > > > productivity you can get from having a set of
                  > > > > re-usable components is huge,
                  > > > > and JSF components are starting to gain some
                  > > > > traction. If we can provide
                  > > > > support within other frameworks, I guarantee you
                  > > component-oriented
                  > > > > Java-oriented web development (with _and_
                  > > without
                  > > > > AJAX) will take off. And I
                  > > > > don't think that supporting JSF UI components
                  > > > > necessarily means avoiding a
                  > > > > request/response programming model.
                  > > > >
                  > > > > Thoughts?
                  > > >
                  > > > But saying the JSF UIComponents is the standard is
                  > > > like saying EJB 2.0 is 'the' way to handle
                  > > > persistence. To create a global commodity for
                  > > > component/presentation frameworks, you almost need
                  > > a super
                  > > > interface that is much simpler to interact with
                  > > such that
                  > > > tapestry or wicket could define fragmented views
                  > > alongside
                  > > > JSF components. Again, taking lead from portlets.
                  > >
                  > > That's not an accurate analogy. EJB 2.0 isn't out
                  > > yet. JSF is out now, and
                  > > so is Tapestry, Wicket, Echo, Millstone, and other component-based
                  > > frameworks. But if you look at the marketplace, JSF
                  > > actually has the largest
                  > > number of off-the-shelf components, and it's the
                  > > only one that has actually
                  > > attracted vendor interest. And, it is technically a
                  > > standard.
                  > >
                  > > So, even if the JSF component model evolves into
                  > > something else, it makes
                  > > sense to capitalize on the marketplace that's
                  > > already growing.
                  > >
                  > >
                  > > > Then we rely on compositions such that traditional
                  > > MVC
                  > > > JSP views can be maintained as singular component
                  > > with
                  > > > the same degree of controller interaction as a
                  > > full
                  > > > blown JSF component. Really, if you look at JSF's
                  > UIComponent and
                  > > > pull out a super interface with
                  > > only
                  > > > the processXXX methods on it, then you've
                  > > separated
                  > > > out the controller aspect of component
                  > > interaction--
                  > > > same as portlet's actions.
                  > > >
                  > > > The rest of the stateful component overhead is
                  > > > coordinated within the ViewHandler. If you want
                  > > to go
                  > > > stateless in your presentation layer, then you go
                  > > with an
                  > > > alternate ViewHandler for Velocity or JSP.
                  > >
                  > > The idea of having compositional, stateless
                  > > components, makes plenty of
                  > > sense to me. It's sort of a different type of beast,
                  > > though -- sort of like
                  > > ASP.NET's User Controls. From what I can tell, RIFE
                  > > does this quite well
                  > > (Geert, please correct me if I'm wrong).
                  > >
                  > > > I'm sure a lot of you are hesitant about JSF, but
                  > > the
                  > > > pieces are there. They aren't perfect, but the
                  > > > opportunity has already been proven with
                  > > struts-faces,
                  > > > shale, and seam. I'm sure continuations could be
                  > > > thrown into the mix too. We just resolve the
                  > > > UIComponent lock-in and now you can basically take
                  > > any
                  > > > framework out there and model/integrate it into
                  > > JSF as they stand now.
                  > >
                  > > I actually think the component side of things is
                  > > more important than the
                  > > basic controller side of things.
                  > >
                  > > >
                  > > > The reason why I've been looking for framework
                  > > support
                  > > > with other component models is there's lots of
                  > > > opportunity to take JSF's component implementation
                  > > > into the EJB 3.0 realm of advancement. So this
                  > > > group's goals aside, if JSF is able to peel itself
                  > > > away from direct UIComponent interface interation,
                  > > > then there's a whole other level of possibilities
                  > > to
                  > > > increase the longevity of the framework or more
                  > > > literally, the 'platform'....
                  > >
                  > > Can you elaborate? You're not talking about tying it
                  > > directly to EJB 3.0,
                  > > are you?
                  > >
                  > > - Kito
                  > >
                  > >
                  >
                • James Mitchell
                  Sorry, I don t mean to be a lurker here, I m actually pretty busy this and last week, but I m sure I m preaching to the choir here so I ll stop. I ll send my
                  Message 8 of 22 , Nov 3, 2005
                  • 0 Attachment
                    Sorry, I don't mean to be a lurker here, I'm actually pretty busy
                    this and last week, but I'm sure I'm preaching to the choir here so
                    I'll stop.

                    I'll send my response first thing tomorrow. It's half written, but
                    I'm so exhausted I'm floating in and out of consciousness as I type
                    this.



                    --
                    James Mitchell
                    678.910.8017




                    On Nov 2, 2005, at 9:26 PM, Kito D. Mann wrote:

                    > So, does anyone else have any comments on these goals? Am I totally
                    > off
                    > base?
                    >
                    > > -----Original Message-----
                    > > From: java_web_alignment@yahoogroups.com
                    > > [mailto:java_web_alignment@yahoogroups.com] On Behalf Of Kito D.
                    > Mann
                    > > Sent: Friday, October 28, 2005 8:44 PM
                    > > To: java_web_alignment@yahoogroups.com
                    > > Subject: [java_web_alignment] Goals
                    > >
                    > >
                    > > Hello everyone,
                    > >
                    > > First of all, I want to thank everyone for joining this
                    > > group. I had been thinking of starting it for a while, and
                    > > after talking to Geert and Patrick at conferences in the past
                    > > couple of months, I finally did it. So far, there are 36 members.
                    > >
                    > > First, let's examine the description of this group:
                    > >
                    > > "The Java web framework landscape has become quite
                    > > fragmented; the purpose of this group is to explore synergies
                    > > among the existing frameworks that will make life easier for
                    > > companies, organizations, and developers using Java to build
                    > > web applications."
                    > >
                    > > This is admittedly vague, but the key point is this: the
                    > > market place is too fragmented (I like choice, but 50 choices
                    > > is too many, even if only 10 of them are any good), and this
                    > > fragmentation causes problems such as difficulty in skills
                    > > transfer between frameworks, confusion at the management and
                    > > entry level, and higher costs for developers of UI
                    > > components, IDE plugins, and other high-productivity tools.
                    > > Anything we can do to address these issues would be a Good Thing.
                    > >
                    > > Now that some people have become quite vocal (still a small
                    > > percentage, I should point out) and I have a sense of
                    > > people's thoughts, I'd like to take my second stab at stating
                    > > some possible goals (the first stab is at
                    > > http://groups.yahoo.com/group/java_web_alignment/message/31).
                    > >
                    > > (1) Identify common elements (patterns, practices, and
                    > > metaphors) and across some of our web frameworks. Come up
                    > > with a common vocabulary for these elements.
                    > > - Possible elements include: user interface components,
                    > > components (in general), Action controllers, continuations,
                    > > AJAX support, domain integration, Dependency Injection support, etc.
                    > > - Ted's use-cases suggestion might be a good way to start
                    > > this process.
                    > >
                    > > (2) For some elements, either choose an existing
                    > > implementation (such as JSF components, EL, or RIFE
                    > > continuation support) or build a new one
                    > > - Allow interaction at the API level
                    > > - Allow interaction at the tool level
                    > > - In places where we can't agree upon an implementation,
                    > > provide a pluggable wrapper
                    > >
                    > > (3) Provide support among different frameworks for these elements
                    > >
                    > > (4) Consider merging some frameworks (i.e. Clarity)
                    > >
                    > > (5) Develop a comparison matrix and/or site to help educate
                    > > people about the different frameworks
                    > > - Also provide information that might _diminish_ the desire
                    > > of others to create frameworks that duplicate existing
                    > > functionality (and don't provide added value). This info
                    > > might include common elements that can be used in new and
                    > > existing frameworks.
                    > >
                    > > (6) Evaluate ways we can make all of our frameworks more
                    > > agile and competitive with offerings such as Ruby on Rails or
                    > ASP.NET
                    > >
                    > > I'd like to officially punt on the following concepts (I
                    > > think this is the general consensus, as well):
                    > >
                    > > - Worrying about other platforms (.NET, PHP, Ruby, etc.). If
                    > > anything great comes out of this group, then it will be
                    > > ported if there's a need. We should, however, strive for
                    > > solutions that are elegant enough for people to _want_ to port them.
                    > >
                    > > - Creating an uber-framework. If a new framework emerges (or
                    > > if Clarity grows or changes due to this group), that's great.
                    > > I think it's safer to focus on smaller goals, like just
                    > > making things work together where possible.
                    > >
                    > > - Turning this into a JSR. It's too early to do anything
                    > > formal with this group; I'd prefer that we try and *do*
                    > > something first :-).
                    > >
                    > > One last point. I don't think everyone realizes the magnitude
                    > > of having a true UI component model for Java web
                    > > applications. The amount of productivity you can get from
                    > > having a set of re-usable components is huge, and JSF
                    > > components are starting to gain some traction. If we can
                    > > provide support within other frameworks, I guarantee you
                    > > component-oriented Java-oriented web development (with _and_
                    > > without AJAX) will take off. And I don't think that
                    > > supporting JSF UI components necessarily means avoiding a
                    > > request/response programming model.
                    > >
                    > > Thoughts?
                    > >
                    > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                    > > Kito D. Mann (kmann@...)
                    > > Principal Consultant, Virtua, Inc. (http://www.virtua.com)
                    > > Author, JavaServer Faces in Action
                    > > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
                    > > phone: 203-323-1244 fax: 203-323-2363
                    > >
                    >
                    >
                    > YAHOO! GROUPS LINKS
                    >
                    > Visit your group "java_web_alignment" on the web.
                    >
                    > To unsubscribe from this group, send an email to:
                    > java_web_alignment-unsubscribe@yahoogroups.com
                    >
                    > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                    >
                    >
                  • Geert Bevin
                    ... Correct, it makes a lot of sense since you get portlet-style mini applications that can incorporate an entire flow inside an area of the view of another
                    Message 9 of 22 , Nov 4, 2005
                    • 0 Attachment
                      >> Then we rely on compositions such that traditional MVC
                      >> JSP views can be maintained as singular component with
                      >> the same degree of controller interaction as a full
                      >> blown JSF component. Really, if you look at JSF's
                      >> UIComponent and pull out a super interface with only
                      >> the processXXX methods on it, then you've separated
                      >> out the controller aspect of component interaction--
                      >> same as portlet's actions.
                      >>
                      >> The rest of the stateful component overhead is
                      >> coordinated within the ViewHandler. If you want to go
                      >> stateless in your presentation layer, then you go with an
                      >> alternate ViewHandler for Velocity or JSP.
                      >
                      > The idea of having compositional, stateless components, makes
                      > plenty of
                      > sense to me. It's sort of a different type of beast, though -- sort
                      > of like
                      > ASP.NET's User Controls. From what I can tell, RIFE does this quite
                      > well
                      > (Geert, please correct me if I'm wrong).

                      Correct, it makes a lot of sense since you get portlet-style mini
                      applications that can incorporate an entire flow inside an area of
                      the view of another component. You can also use the same application
                      directly and link it in the middle of the flow of existing state
                      transitions.

                      --
                      Geert Bevin Uwyn bvba
                      "Use what you need" Avenue de Scailmont 34
                      http://www.uwyn.com 7170 Manage, Belgium
                      gbevin[remove] at uwyn dot com Tel +32 64 84 80 03

                      PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
                      Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
                    • Geert Bevin
                      Hi Kito, I think this is a great summary of everything that has been discussed. I m personally more behind 1 and 5 in the context of this group. I think that 6
                      Message 10 of 22 , Nov 4, 2005
                      • 0 Attachment
                        Hi Kito,

                        I think this is a great summary of everything that has been discussed.

                        I'm personally more behind 1 and 5 in the context of this group.
                        I think that 6 is extremely important, but it's more related to the
                        specifics of each framework. However, lobbying for general features
                        that makes this more easy to achieve (like enhanced hotswap - http://
                        rifers.org/blogs/gbevin/2005/10/31/hotswap_improvement) could be a
                        common goal.

                        > One last point. I don't think everyone realizes the magnitude of
                        > having a
                        > true UI component model for Java web applications. The amount of
                        > productivity you can get from having a set of re-usable components
                        > is huge,
                        > and JSF components are starting to gain some traction. If we can
                        > provide
                        > support within other frameworks, I guarantee you component-oriented
                        > Java-oriented web development (with _and_ without AJAX) will take
                        > off. And I
                        > don't think that supporting JSF UI components necessarily means
                        > avoiding a
                        > request/response programming model.
                        >
                        > Thoughts?

                        I'm totally behind the given that a set of reusable components is a
                        big gain for web application development. I'm however very skeptical
                        that this is possible in one way that works everywhere. I however
                        plan on reading your book as soon as I have some time and learn how
                        JSF does this. How is this related to portlets? Couldn't they be
                        adopted as components too?

                        Best regards,

                        Geert

                        --
                        Geert Bevin Uwyn bvba
                        "Use what you need" Avenue de Scailmont 34
                        http://www.uwyn.com 7170 Manage, Belgium
                        gbevin[remove] at uwyn dot com Tel +32 64 84 80 03

                        PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
                        Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
                      • Geert Bevin
                        ... Hi Jacob, I can only talk for RIFE, and I will attempt to do so without writing an entire book ;-) Our approach starts from regular request/response CGI
                        Message 11 of 22 , Nov 4, 2005
                        • 0 Attachment
                          > I would really like to hear about other approaches to
                          > component development-- sounds like Rife has a
                          > different approach, along with WebWork.

                          Hi Jacob,

                          I can only talk for RIFE, and I will attempt to do so without writing
                          an entire book ;-)

                          Our approach starts from regular request/response CGI pages. Each
                          page receives data, provides data and has exit points that lead to
                          the next step in the flow. We also took the basic approach that each
                          page handles its own form submissions and triggers an exit for the
                          next step. All this declares a black box that can look like this, we
                          call it an element:
                        • jacob hookom
                          From the 30,000 foot view, Rife components are stateless(?)-- such that appropriate state would be retained in the view or some other scope manually,
                          Message 12 of 22 , Nov 4, 2005
                          • 0 Attachment
                            From the 30,000 foot view, Rife components are
                            stateless(?)-- such that appropriate state would be
                            retained in the view or some other scope manually,
                            independent of the component instance?

                            Do components take on multiple roles-- like JSF, such
                            that they can take part in the 5 MVC steps, decode,
                            validation, update, invoke, and encode (render)? Or
                            is it more similar to straight JSP tags with a single
                            event?

                            Thanks,
                            Jacob

                            --- Geert Bevin <gbevin@...> wrote:

                            > > I would really like to hear about other approaches
                            > to
                            > > component development-- sounds like Rife has a
                            > > different approach, along with WebWork.
                            >
                            > Hi Jacob,
                            >
                            > I can only talk for RIFE, and I will attempt to do
                            > so without writing
                            > an entire book ;-)
                            >
                            > Our approach starts from regular request/response
                            > CGI pages. Each
                            > page receives data, provides data and has exit
                            > points that lead to
                            > the next step in the flow. We also took the basic
                            > approach that each
                            > page handles its own form submissions and triggers
                            > an exit for the
                            > next step. All this declares a black box that can
                            > look like this, we
                            > call it an element:
                            >
                            > >
                            >
                            > Now, there's nothing that says where the data comes
                            > from, nor where
                            > is goes to, nor is there anything that says in which
                            > context it lives.
                            >
                            > The next step was to dissociate the element from the
                            > actual HTTP
                            > request/response and to make the data flow and logic
                            > flow live as a
                            > sort of state machine that can optionally transfer
                            > state over the
                            > HTTP network barrier, but doesn't have to.
                            >
                            > Now, everything in RIFE must be declared in a
                            > site-structure that
                            > look a bit like this:
                            >
                            > >
                            >
                            > This allows RIFE to have complete knowledge of all
                            > the state
                            > transitions.
                            >
                            > This entire structure can be packaged as an element
                            > too, with its own
                            > data inputs, outputs and exits.
                            >
                            > Since RIFE has complete control over the data
                            > transfer, you are able
                            > to embed any element (and thus also an entire
                            > site-structure or
                            > application) inside the view of any other element.
                            > The web engine
                            > will make sure that the containing elements will be
                            > refreshed with
                            > their current data inputs (only submissions are
                            > supposed to change
                            > back-end state) and that the new data arrives at the
                            > appropriate
                            > embedded element.
                            >
                            > We then go a step further. You can also layer any
                            > element (and thus
                            > also any application) on top of another element and
                            > declare trigger
                            > conditions that will make the flow step down to the
                            > underlying layer.
                            > This is how we do authentication, for instance: only
                            > when the correct
                            > trigger condition is present in the upper layer
                            > (authenticated user),
                            > the flow falls down to the layer below. Again, RIFE
                            > knows which data
                            > was sent to the underlying layer and who it was
                            > intended for. This
                            > makes it possible to, for instance, have a form that
                            > is being filled
                            > in, have an authenticated session timeout that
                            > occurs, go through the
                            > entire flow of the authentication layer, drop down
                            > and provide the
                            > original submitted data to the intended element
                            > without losing what
                            > the user sent (more info here:
                            >
                            http://rifers.org/blogs/gbevin/2005/3/15/session_timeout_solution).
                            >
                            > This is the basis of our component model. On the
                            > inside of an element
                            > implementation, you just work as if you received the
                            > data directly
                            > through HTTP and RIFE takes care of giving it
                            > correctly to the
                            > element depending on the context and scope in which
                            > the element lives.
                            >
                            > I hope this is clear enough, it just skims the
                            > surface. There are
                            > many more features to the web engine, but it should
                            > give you an idea
                            > of the basics.
                            >
                            > Best regards,
                            >
                            > Geert
                            >
                            > --
                            > Geert Bevin Uwyn bvba
                            > "Use what you need" Avenue de
                            > Scailmont 34
                            > http://www.uwyn.com 7170 Manage,
                            > Belgium
                            > gbevin[remove] at uwyn dot com Tel +32 64 84 80
                            > 03
                            >
                            > PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A
                            > C8F4 D40D 309F D6A9
                            > Public PGP key : available at servers pgp.mit.edu,
                            > wwwkeys.pgp.net
                            >
                            >
                            >




                            __________________________________
                            Yahoo! FareChase: Search multiple travel sites in one click.
                            http://farechase.yahoo.com
                          • Geert Bevin
                            ... Yes, state is stored outside the component, based on the data flow. By default this is in the view / request, but other state stores are also available.
                            Message 13 of 22 , Nov 4, 2005
                            • 0 Attachment
                              > From the 30,000 foot view, Rife components are
                              > stateless(?)-- such that appropriate state would be
                              > retained in the view or some other scope manually,
                              > independent of the component instance?

                              Yes, state is stored outside the component, based on the data flow.
                              By default this is in the view / request, but other state stores are
                              also available. This keeps the state together with the steps in the
                              history without having to track them in a versioning system on the
                              server-side.

                              > Do components take on multiple roles-- like JSF, such
                              > that they can take part in the 5 MVC steps, decode,
                              > validation, update, invoke, and encode (render)? Or
                              > is it more similar to straight JSP tags with a single
                              > event?

                              Multiple roles. Nothing says what a component can or can't do. The
                              only recommendation is to put non idempotent actions in submissions
                              to prevent side effects from happening.


                              --
                              Geert Bevin Uwyn bvba
                              "Use what you need" Avenue de Scailmont 34
                              http://www.uwyn.com 7170 Manage, Belgium
                              gbevin[remove] at uwyn dot com Tel +32 64 84 80 03

                              PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
                              Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
                            • jacob hookom
                              Thanks, if you don t mind, I m just trying to determin how Rife components relate to the behavior of JSF components: 1. How are iterative contexts handled,
                              Message 14 of 22 , Nov 4, 2005
                              • 0 Attachment
                                Thanks, if you don't mind, I'm just trying to determin
                                how Rife components relate to the behavior of JSF
                                components:

                                1. How are iterative contexts handled, where the
                                component could be part of a row in a large table of
                                data? State is managed externally in Rife, the
                                coordination of relating that state to a particular
                                row instance?

                                2. How easy is it for vendors to deliver rich
                                components in your opinion-- to be able to package
                                functionality, such as Crystal Reports would with
                                displaying an image and functional controls. Is it
                                inherent in the framework that the behavioral
                                coordination of those components doesn't need to be
                                delegated to a separate controller declaration?

                                I hope I made some sense :-)

                                Relating to UIComponent to controller expectations,
                                the opportunity for the view to first be restored or
                                bound and optionally pass an-- I'm going to use
                                WebWork as an example-- ActionMapping to the
                                controller or ActionEvent to the controller for
                                processing instead of locking controller invocation by
                                URI.

                                -- Jacob

                                --- Geert Bevin <gbevin@...> wrote:

                                > > From the 30,000 foot view, Rife components are
                                > > stateless(?)-- such that appropriate state would
                                > be
                                > > retained in the view or some other scope manually,
                                > > independent of the component instance?
                                >
                                > Yes, state is stored outside the component, based on
                                > the data flow.
                                > By default this is in the view / request, but other
                                > state stores are
                                > also available. This keeps the state together with
                                > the steps in the
                                > history without having to track them in a versioning
                                > system on the
                                > server-side.
                                >
                                > > Do components take on multiple roles-- like JSF,
                                > such
                                > > that they can take part in the 5 MVC steps,
                                > decode,
                                > > validation, update, invoke, and encode (render)?
                                > Or
                                > > is it more similar to straight JSP tags with a
                                > single
                                > > event?
                                >
                                > Multiple roles. Nothing says what a component can or
                                > can't do. The
                                > only recommendation is to put non idempotent actions
                                > in submissions
                                > to prevent side effects from happening.
                                >
                                >
                                > --
                                > Geert Bevin Uwyn bvba
                                > "Use what you need" Avenue de
                                > Scailmont 34
                                > http://www.uwyn.com 7170 Manage,
                                > Belgium
                                > gbevin[remove] at uwyn dot com Tel +32 64 84 80
                                > 03
                                >
                                > PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A
                                > C8F4 D40D 309F D6A9
                                > Public PGP key : available at servers pgp.mit.edu,
                                > wwwkeys.pgp.net
                                >
                                >
                                >




                                __________________________________
                                Yahoo! FareChase: Search multiple travel sites in one click.
                                http://farechase.yahoo.com
                              • Geert Bevin
                                ... Since the views (templates) contain no logic at all, this is handled by doing the iteration in the view logic and associating a differentiator to each
                                Message 15 of 22 , Nov 4, 2005
                                • 0 Attachment
                                  On 4-nov-05, at 17:46, jacob hookom wrote:

                                  > Thanks, if you don't mind, I'm just trying to determin
                                  > how Rife components relate to the behavior of JSF
                                  > components:
                                  >
                                  > 1. How are iterative contexts handled, where the
                                  > component could be part of a row in a large table of
                                  > data? State is managed externally in Rife, the
                                  > coordination of relating that state to a particular
                                  > row instance?

                                  Since the views (templates) contain no logic at all, this is handled
                                  by doing the iteration in the view logic and associating a
                                  differentiator to each component instance. It's the responsibility of
                                  the view logic to ensure that the correct differentiator is always
                                  used for the related instance.

                                  > 2. How easy is it for vendors to deliver rich
                                  > components in your opinion-- to be able to package
                                  > functionality, such as Crystal Reports would with
                                  > displaying an image and functional controls. Is it
                                  > inherent in the framework that the behavioral
                                  > coordination of those components doesn't need to be
                                  > delegated to a separate controller declaration?

                                  That's part of the original design. We already ship rich components
                                  like an embeddable blog and forum. The can just be package in a jar
                                  and dropped into WEB-INF/lib.

                                  > I hope I made some sense :-)
                                  >
                                  > Relating to UIComponent to controller expectations,
                                  > the opportunity for the view to first be restored or
                                  > bound and optionally pass an-- I'm going to use
                                  > WebWork as an example-- ActionMapping to the
                                  > controller or ActionEvent to the controller for
                                  > processing instead of locking controller invocation by
                                  > URI.

                                  Nothing in RIFE is bound to the URL and the framework generates all
                                  URLs automatically. This means that any component can sit in any
                                  context according to the site-structure declaration.

                                  --
                                  Geert Bevin Uwyn bvba
                                  "Use what you need" Avenue de Scailmont 34
                                  http://www.uwyn.com 7170 Manage, Belgium
                                  gbevin[remove] at uwyn dot com Tel +32 64 84 80 03

                                  PGP Fingerprint : 4E21 6399 CD9E A384 6619 719A C8F4 D40D 309F D6A9
                                  Public PGP key : available at servers pgp.mit.edu, wwwkeys.pgp.net
                                • James Mitchell
                                  Again, sorry for not responding sooner, I don t really have specific goals or expectations, but I can appreciate the list below. To be completely honest, I m
                                  Message 16 of 22 , Nov 5, 2005
                                  • 0 Attachment
                                    Again, sorry for not responding sooner,

                                    I don't really have specific goals or expectations, but I can
                                    appreciate the list below.

                                    To be completely honest, I'm tired of assembling web applications
                                    page by page, action by action. If the goal was to build a car, at
                                    least with the current set of frameworks, I'm not reinventing the
                                    wheel every time. However, I do feel like I'm having to build the
                                    client a new car every time from simple components. Something should
                                    happen in this space if it hasn't already.

                                    I've done Struts for many years, so when I had the chance to build a
                                    SWT-based application, I jumped on it. I've been doing that for
                                    about 6 months, which has given me a new appreciation for component-
                                    based, event-driven development, and I recently picked up a new
                                    client who wants a JSF app built.

                                    Coming from Struts, I don't really feel like I've taken a giant step
                                    up from the old action based apps with JSF. I understand the payoff
                                    of using the specification over any of the other frameworks.
                                    However, similar to what I stated above, I'm still building this
                                    thing screen by screen, page by page, backing bean by backing
                                    bean....and I'm *really* tired of being in xml hell.

                                    With most web applications (at least what I've typically done),
                                    there are always elements that are reusable across any of them, and I
                                    don't mean between areas of an app, but literally between apps.

                                    I have yet to find a framework that let's me build my application
                                    independently of the Controller and View implementations. I'm not
                                    talking about full blown MDA, but something with at least enough
                                    abstraction so I'm not 'tied to' or 'bogged down in' a particular
                                    implementation and it's flaws.

                                    What I want is a simple platform for building applications that any
                                    particular framework implementation can use as a base configuration.
                                    So, for example, if I created a MailreaderApplicationConfiguration, I
                                    could then configure the Tapestry extension servlet and on
                                    deployment, the application would basically be a Tapestry
                                    application, yet I never typed a single Tapestry-specific line of
                                    code. Switching to WebWork might be as simple as repackaging with
                                    the WebWork extension, changing one line in the spring-beans.xml and
                                    redeploy. Next, I should be able to repackage the app and configure
                                    to use the SwingExtension and now I have a fully functioning Swing
                                    based application that I can deliver as an install or via web start.

                                    The views would be handled by a large set of implemented view
                                    configurations that implemented everything from entire sets of
                                    functionality (Blogger, UserAdministration, etc) or individual
                                    dialogs (LoginDialog, SearchDialog, DetailDialog), yet allow fine
                                    grained control over the styles of a particular navigation button or
                                    link.

                                    I guess what I really want is something akin to what SWT and the
                                    Eclipse RCP provides for gui app development. Write it once and
                                    deploy it natively across all platforms. SWT provides the OS
                                    specific hooks and event handling, and everything else is built on
                                    top of that. May not be the best parallel, but it works in this
                                    context.

                                    And no, I don't mean code generation. Ok, so if you think I'm crazy,
                                    I'm cool with that. I've been called worse ;)


                                    --
                                    James Mitchell
                                    678.910.8017




                                    On Nov 2, 2005, at 9:26 PM, Kito D. Mann wrote:

                                    So, does anyone else have any comments on these goals? Am I totally off
                                    base?

                                    > -----Original Message-----
                                    > From: java_web_alignment@yahoogroups.com
                                    > [mailto:java_web_alignment@yahoogroups.com] On Behalf Of Kito D. Mann
                                    > Sent: Friday, October 28, 2005 8:44 PM
                                    > To: java_web_alignment@yahoogroups.com
                                    > Subject: [java_web_alignment] Goals
                                    >
                                    >
                                    > Hello everyone,
                                    >
                                    > First of all, I want to thank everyone for joining this
                                    > group. I had been thinking of starting it for a while, and
                                    > after talking to Geert and Patrick at conferences in the past
                                    > couple of months, I finally did it. So far, there are 36 members.
                                    >
                                    > First, let's examine the description of this group:
                                    >
                                    > "The Java web framework landscape has become quite
                                    > fragmented; the purpose of this group is to explore synergies
                                    > among the existing frameworks that will make life easier for
                                    > companies, organizations, and developers using Java to build
                                    > web applications."
                                    >
                                    > This is admittedly vague, but the key point is this: the
                                    > market place is too fragmented (I like choice, but 50 choices
                                    > is too many, even if only 10 of them are any good), and this
                                    > fragmentation causes problems such as difficulty in skills
                                    > transfer between frameworks, confusion at the management and
                                    > entry level, and higher costs for developers of UI
                                    > components, IDE plugins, and other high-productivity tools.
                                    > Anything we can do to address these issues would be a Good Thing.
                                    >
                                    > Now that some people have become quite vocal (still a small
                                    > percentage, I should point out) and I have a sense of
                                    > people's thoughts, I'd like to take my second stab at stating
                                    > some possible goals (the first stab is at
                                    > http://groups.yahoo.com/group/java_web_alignment/message/31).
                                    >
                                    > (1) Identify common elements (patterns, practices, and
                                    > metaphors) and across some of our web frameworks. Come up
                                    > with a common vocabulary for these elements.
                                    > - Possible elements include: user interface components,
                                    > components (in general), Action controllers, continuations,
                                    > AJAX support, domain integration, Dependency Injection support, etc.
                                    > - Ted's use-cases suggestion might be a good way to start
                                    > this process.
                                    >
                                    > (2) For some elements, either choose an existing
                                    > implementation (such as JSF components, EL, or RIFE
                                    > continuation support) or build a new one
                                    > - Allow interaction at the API level
                                    > - Allow interaction at the tool level
                                    > - In places where we can't agree upon an implementation,
                                    > provide a pluggable wrapper
                                    >
                                    > (3) Provide support among different frameworks for these elements
                                    >
                                    > (4) Consider merging some frameworks (i.e. Clarity)
                                    >
                                    > (5) Develop a comparison matrix and/or site to help educate
                                    > people about the different frameworks
                                    > - Also provide information that might _diminish_ the desire
                                    > of others to create frameworks that duplicate existing
                                    > functionality (and don't provide added value). This info
                                    > might include common elements that can be used in new and
                                    > existing frameworks.
                                    >
                                    > (6) Evaluate ways we can make all of our frameworks more
                                    > agile and competitive with offerings such as Ruby on Rails or ASP.NET
                                    >
                                    > I'd like to officially punt on the following concepts (I
                                    > think this is the general consensus, as well):
                                    >
                                    > - Worrying about other platforms (.NET, PHP, Ruby, etc.). If
                                    > anything great comes out of this group, then it will be
                                    > ported if there's a need. We should, however, strive for
                                    > solutions that are elegant enough for people to _want_ to port them.
                                    >
                                    > - Creating an uber-framework. If a new framework emerges (or
                                    > if Clarity grows or changes due to this group), that's great.
                                    > I think it's safer to focus on smaller goals, like just
                                    > making things work together where possible.
                                    >
                                    > - Turning this into a JSR. It's too early to do anything
                                    > formal with this group; I'd prefer that we try and *do*
                                    > something first :-).
                                    >
                                    > One last point. I don't think everyone realizes the magnitude
                                    > of having a true UI component model for Java web
                                    > applications. The amount of productivity you can get from
                                    > having a set of re-usable components is huge, and JSF
                                    > components are starting to gain some traction. If we can
                                    > provide support within other frameworks, I guarantee you
                                    > component-oriented Java-oriented web development (with _and_
                                    > without AJAX) will take off. And I don't think that
                                    > supporting JSF UI components necessarily means avoiding a
                                    > request/response programming model.
                                    >
                                    > Thoughts?
                                    >
                                    > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                    > Kito D. Mann (kmann@...)
                                    > Principal Consultant, Virtua, Inc. (http://www.virtua.com)
                                    > Author, JavaServer Faces in Action
                                    > http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
                                    > phone: 203-323-1244 fax: 203-323-2363
                                    >
                                  • Adam Winer
                                    Kito, I m just back from vacation, so time for me to jump in here... I think it s critical that we identify useful sub-projects that can be meaningfully
                                    Message 17 of 22 , Nov 8, 2005
                                    • 0 Attachment
                                      Kito,

                                      I'm just back from vacation, so time for me to jump in here...

                                      I think it's critical that we identify useful sub-projects that can be
                                      meaningfully tackled instead of building castles in the air.

                                      I'm skeptical that "educating users on the differences between the
                                      frameworks" can be done well - I suspect this will rapidly devolve
                                      into a smackdown session, perhaps entertaining to onlookers but of
                                      little practical use.

                                      A couple of sub-projects have been mentioned on this list that I
                                      believe could bear fruit, and a couple of other possibilities come to
                                      mind:

                                      - Design POJO annotations/metadata/etc. at the model layer that can be
                                      supported by all web frameworks, as Jacob suggested. Seam and EJB 3
                                      are a decent starting point.

                                      - Investigate what it would take to support JSF components for
                                      presentation logic inside request-response frameworks. There's lots
                                      of JSF components out there, and more and more coming. It's a nice
                                      win if request-response frameworks can support these component
                                      libraries. You can flip this issue on its head, of course, and phrase
                                      it as "what would it take to make support request-response frameworks
                                      for controller logic inside JSF?"

                                      - "EL" unification - allow users to choose OGNL vs. EE EL in all
                                      frameworks; give users managed beans/Spring/any-IoC access in all EL
                                      environments, if and when they choose.

                                      - Support rampant stealing of ideas across frameworks. For example,
                                      in what ways are the Tapestry, JSF, Wicket, etc. component libraries
                                      better/worse than each other, and how can each framework ruthlessly
                                      rip off the good bits from the others?

                                      I don't yet see this as a group that actually resolves issues
                                      directly, but instead as one that identifies issues and forks off
                                      groups to directly tackle them.

                                      Cheers,
                                      Adam Winer
                                    • Martijn Dashorst
                                      ... I think you just want a better JSF implementation :-). Seriously. Wicket and Tapestry are very alike, but different enough to ensure we probably won t be
                                      Message 18 of 22 , Nov 8, 2005
                                      • 0 Attachment
                                        On 11/6/05, James Mitchell <james.l.mitchell@...> wrote:
                                        > What I want is a simple platform for building applications that any
                                        > particular framework implementation can use as a base configuration.
                                        > So, for example, if I created a
                                        > MailreaderApplicationConfiguration, I
                                        > could then configure the Tapestry extension servlet and on
                                        > deployment, the application would basically be a Tapestry
                                        > application, yet I never typed a single Tapestry-specific line of
                                        > code. Switching to WebWork might be as simple as repackaging with
                                        > the WebWork extension, changing one line in the spring-beans.xml and
                                        > redeploy. Next, I should be able to repackage the app and configure
                                        > to use the SwingExtension and now I have a fully functioning Swing
                                        > based application that I can deliver as an install or via web start.

                                        I think you just want a better JSF implementation :-). Seriously.
                                        Wicket and Tapestry are very alike, but different enough to ensure we
                                        probably won't be able to use each others components.

                                        I doubt that it will be conceivable that all frameworks could be
                                        mapped into a generic component model. Action oriented frameworks are
                                        neigh impossible to map onto component oriented frameworks. And even
                                        when it is possible, I don't think anyone would really like the
                                        outcome, as it would tie the hands of all frameworks, stiffling
                                        innovation. Or, some rogue framework would ultimately emerge and steal
                                        our wind ;-)

                                        I really like that we have several competing frameworks, such as
                                        webwork, wicket, tapestry and rife. I also like when the frameworks
                                        join forces and help the Java landscape progress, such as a joined
                                        effort for continuations, java class(re)loading improvements or
                                        contributing back to projects such as Dojo and scriptaculous.

                                        I think the allignment group is a great platform for discussing the
                                        different approaches each framework provides, and for trying to find
                                        common ground for common problems such as the continuations, class
                                        reloading and so forth. IMO a generic (web) UI model would be either
                                        too general, or too limiting to be of real use.

                                        Martijn Dashorst

                                        --
                                        Living a wicket life...

                                        Martijn Dashorst - http://www.jroller.com/page/dashorst

                                        Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1
                                      • James Mitchell
                                        I think maybe I didn t explain my vision very well. While this isn t some new revolutionary idea, the Standard Widget Toolkit provides me with an OS agnostic
                                        Message 19 of 22 , Nov 10, 2005
                                        • 0 Attachment
                                          I think maybe I didn't explain my vision very well.

                                          While this isn't some new revolutionary idea, the Standard Widget
                                          Toolkit provides me with an OS agnostic way to create an application
                                          that ultimately hooks into the host Operating System's native
                                          windowing api. Through OS specific extensions, the framework
                                          provides me with everything I need to write an application that runs
                                          natively (not carrying along and using it's own windowing manager) on
                                          MS Windows, OS X, etc.

                                          I don't see why this can't be done on a larger scale. Give me a few
                                          days and I'll put my money where my mouth is.

                                          --
                                          James Mitchell
                                          678.910.8017




                                          On Nov 8, 2005, at 6:18 PM, Martijn Dashorst wrote:

                                          > On 11/6/05, James Mitchell <james.l.mitchell@...> wrote:
                                          > > What I want is a simple platform for building applications that any
                                          > > particular framework implementation can use as a base
                                          > configuration.
                                          > > So, for example, if I created a
                                          > > MailreaderApplicationConfiguration, I
                                          > > could then configure the Tapestry extension servlet and on
                                          > > deployment, the application would basically be a Tapestry
                                          > > application, yet I never typed a single Tapestry-specific line of
                                          > > code. Switching to WebWork might be as simple as repackaging with
                                          > > the WebWork extension, changing one line in the spring-beans.xml
                                          > and
                                          > > redeploy. Next, I should be able to repackage the app and
                                          > configure
                                          > > to use the SwingExtension and now I have a fully functioning Swing
                                          > > based application that I can deliver as an install or via web
                                          > start.
                                          >
                                          > I think you just want a better JSF implementation :-). Seriously.
                                          > Wicket and Tapestry are very alike, but different enough to ensure we
                                          > probably won't be able to use each others components.
                                          >
                                          > I doubt that it will be conceivable that all frameworks could be
                                          > mapped into a generic component model. Action oriented frameworks are
                                          > neigh impossible to map onto component oriented frameworks. And even
                                          > when it is possible, I don't think anyone would really like the
                                          > outcome, as it would tie the hands of all frameworks, stiffling
                                          > innovation. Or, some rogue framework would ultimately emerge and steal
                                          > our wind ;-)
                                          >
                                          > I really like that we have several competing frameworks, such as
                                          > webwork, wicket, tapestry and rife. I also like when the frameworks
                                          > join forces and help the Java landscape progress, such as a joined
                                          > effort for continuations, java class(re)loading improvements or
                                          > contributing back to projects such as Dojo and scriptaculous.
                                          >
                                          > I think the allignment group is a great platform for discussing the
                                          > different approaches each framework provides, and for trying to find
                                          > common ground for common problems such as the continuations, class
                                          > reloading and so forth. IMO a generic (web) UI model would be either
                                          > too general, or too limiting to be of real use.
                                          >
                                          > Martijn Dashorst
                                          >
                                          > --
                                          > Living a wicket life...
                                          >
                                          > Martijn Dashorst - http://www.jroller.com/page/dashorst
                                          >
                                          > Wicket 1.1 is out: http://wicket.sourceforge.net/wicket-1.1
                                          >
                                          >
                                          > SPONSORED LINKS
                                          > C programming language Computer programming languages Java
                                          > programming language
                                          > The c programming language C programming language Concept of
                                          > programming language
                                          >
                                          > YAHOO! GROUPS LINKS
                                          >
                                          > Visit your group "java_web_alignment" on the web.
                                          >
                                          > To unsubscribe from this group, send an email to:
                                          > java_web_alignment-unsubscribe@yahoogroups.com
                                          >
                                          > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
                                          >
                                          >
                                        Your message has been successfully submitted and would be delivered to recipients shortly.