You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Matthias Wessendorf <ma...@apache.org> on 2007/05/03 18:07:42 UTC
[Proposal] Apache MyFaces commons
Greetings from the ApacheCon in Amsterdam.
It was discussed a lot on the list and Bernd and I are now taking the
time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
Commons:
-What should go into a commons JAR?
Non renderKit related things like
-Converters and Validators
-NonFacesRequestServlet from Tobago
-FacesContextFactory from Tobago to ensure a kind of common layer
for doing uploads
-the selectItems component from Tomahawk
-what are we missing ???
Build dependencies:
- Trinidad's plugins/utils to generate stuff like the TagClass file.
The vision:
Why this is needed ?
It is kind of hard to actually use only some "common" pieces of
Tomahawk. At least to add a custom validator, the complete jar is
needed. The vision is also to add some "common" pieces from
Trinidad/tobago to it.
For Tomahawk this will not mean, you have to introduce a new namespace
for adding the converter/validator, the "commons-jar" can be a rt
dependency so that the TLD file is only referencing to the classes
w/in the commons.jar.
What are you missing ?
We will compile a list into the MyFaces wiki, based on your feedback/comments
-Bernd/Matthias
Re: [Proposal] Apache MyFaces commons
Posted by Matthias Wessendorf <ma...@apache.org>.
> Someone (forget who) was suggesting that the faces Maven
> plugin (currently in Trinidad) should be part of Commons.
> Obviously, a Maven plugin lives in its own JAR. I'm OK
> with having shared build tools in a common SVN tree,
> just so it's clearer for someone working on the project.
> Make sense?
I was trying to say, that for the build of the commons, we should
*use* the maven plugins.
Not sure what I wrote to let is sound like *integrate* it into the commons-jar.
-M
> -- Adam
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Proposal] Apache MyFaces commons
Posted by Adam Winer <aw...@gmail.com>.
On 5/4/07, Sean Schofield <se...@gmail.com> wrote:
> > - Are we looking to define internal utilities shared among
> > Trinidad/Tomahawk/Tobago?
>
> yes that's my understanding
>
> > - Are we looking to define public APIs shared among these
> > projects?
>
> yes common api for these projects but not necessarily immutable
>
> > - Are we going to have a common package name for all
> > such code?
>
> +1
>
> > IMO, we should:
> > - Have no components at all in here, at least to start,
> > whether or not they render markup.
>
> Definitely +1
>
> > - Use a common package name
>
> +1
>
> > - Be very cautious and slow as we build this up, being *really*
> > sure about the APIs we're adding. This should be a foundational
> > stone for a long time.
>
> +1 for go slow
>
> > - Start enforcing a public vs. private API split for real, and
> > be rigorous about when we change public APIs without
> > preserving backwards compatibility.
>
> +0
>
> it would be nice to have stable public API but i don't think that its
> the end of the world if its not stable. primary purpose of this (imo)
> is to promote consolidation and harmony amongst myfaces subprojects.
For some customers (who write certain paychecks :) ), unstable
public APIs *are* the end of the world, in that changed APIs
mean they can't upgrade.
> > Also, I don't think build dependencies belong in here, at least
> > not in terms of a packaged JAR. Whether they live in
> > a "commons" in terms of SVN locations is fine.
>
> not sure what this refers to. please explain.
Someone (forget who) was suggesting that the faces Maven
plugin (currently in Trinidad) should be part of Commons.
Obviously, a Maven plugin lives in its own JAR. I'm OK
with having shared build tools in a common SVN tree,
just so it's clearer for someone working on the project.
Make sense?
-- Adam
Re: [Proposal] Apache MyFaces commons
Posted by Sean Schofield <se...@gmail.com>.
> - Are we looking to define internal utilities shared among
> Trinidad/Tomahawk/Tobago?
yes that's my understanding
> - Are we looking to define public APIs shared among these
> projects?
yes common api for these projects but not necessarily immutable
> - Are we going to have a common package name for all
> such code?
+1
> IMO, we should:
> - Have no components at all in here, at least to start,
> whether or not they render markup.
Definitely +1
> - Use a common package name
+1
> - Be very cautious and slow as we build this up, being *really*
> sure about the APIs we're adding. This should be a foundational
> stone for a long time.
+1 for go slow
> - Start enforcing a public vs. private API split for real, and
> be rigorous about when we change public APIs without
> preserving backwards compatibility.
+0
it would be nice to have stable public API but i don't think that its
the end of the world if its not stable. primary purpose of this (imo)
is to promote consolidation and harmony amongst myfaces subprojects.
> Also, I don't think build dependencies belong in here, at least
> not in terms of a packaged JAR. Whether they live in
> a "commons" in terms of SVN locations is fine.
not sure what this refers to. please explain.
> -- Adam
sean
Re: [Proposal] Apache MyFaces commons
Posted by Mike Kienenberger <mk...@gmail.com>.
Adam,
I was repeating what'd been said before rather than stating an opinion.
However, after thinking about it a little, I think there's two
different products we're talking about.
One product, CommonComponents, is targeted for general JSF developers.
It's stuff that can easily be used in any project no matter what the
rendering kit or other component sets. These people may never create
a component on their own, and theoretically may not even be Java
programmers -- they may be page designers. The "API" for these items
are simply the available attributes on the components.
The other product, CommonAPI, is targeted at component developers.
It's code APIs that allow someone to more quickly and consistently
develop new components. There's nothing here that would directly be
used in an application. The api here has to be far more carefully
considered.
Obviously, these are glaring generalizations, and there's bound to be
some overlap.
On 5/3/07, Adam Winer <aw...@gmail.com> wrote:
> Ahhh! :) Makes much more sense. Like you said,
> I think there's already some confusion, this sets it
> mostly straight. Maybe some naming is in order?
> What about:
> "MyFaces Basics": components/validators/filters, etc.
> that users can use anywhere (== CommonComponents)
> "MyFaces Commons": public APIs that we expose across
> the stack (== CommonAPIs)
> "MyFaces Shared": internal APIs that all the component
> libraries + the impl can collaborate and depend on?
>
> But I'm not 100% convinced that there really is a difference
> between CommonComponents and CommonAPIs, or
> at least enough of a difference to merit splitting them.
> Mike, what about the two makes you want to split
> them?
>
> Cheers,
> Adam
>
>
> On 5/3/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > Adam,
> >
> > Our past discussion on "commons" was to provide JSF
> > components/validators/converters that could be used in any component
> > library, even if that component library is not compatible with any
> > other component library (ie, tobago). I think perhaps this should be
> > called CommonComponents.
> >
> > "Commons" as was used in this thread is not about building a component
> > development API. That is a different but often-brought-up topic that
> > also needs a "vision". We will want a CommonAPI to cover the area
> > that Adam brought up.
> >
> > We should try to be clear about which we're talking about since we're
> > already seeing some confusion in the thread. For example,
> > AddResources would probably be a part of CommonAPI rather than
> > CommonComponents.
> >
> > Note that MyFaces also has a "shared" module where code is shared
> > between MyFaces Core and MyFaces Tomahawk.
> >
> > On 5/3/07, Adam Winer <aw...@gmail.com> wrote:
> > > Before we do this, we have to be careful on our vision:
> > > - Are we looking to define internal utilities shared among
> > > Trinidad/Tomahawk/Tobago?
> > > - Are we looking to define public APIs shared among these
> > > projects?
> > > - Are we going to have a common package name for all
> > > such code?
> > >
> > > IMO, we should:
> > > - Have no components at all in here, at least to start,
> > > whether or not they render markup.
> > > - Use a common package name
> > > - Be very cautious and slow as we build this up, being *really*
> > > sure about the APIs we're adding. This should be a foundational
> > > stone for a long time.
> > > - Start enforcing a public vs. private API split for real, and
> > > be rigorous about when we change public APIs without
> > > preserving backwards compatibility.
> > >
> > > Also, I don't think build dependencies belong in here, at least
> > > not in terms of a packaged JAR. Whether they live in
> > > a "commons" in terms of SVN locations is fine.
> > >
> > > -- Adam
> > >
> > >
> > >
> > > On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > Greetings from the ApacheCon in Amsterdam.
> > > >
> > > > It was discussed a lot on the list and Bernd and I are now taking the
> > > > time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
> > > >
> > > > Commons:
> > > > -What should go into a commons JAR?
> > > > Non renderKit related things like
> > > > -Converters and Validators
> > > > -NonFacesRequestServlet from Tobago
> > > > -FacesContextFactory from Tobago to ensure a kind of common layer
> > > > for doing uploads
> > > > -the selectItems component from Tomahawk
> > > > -what are we missing ???
> > > >
> > > > Build dependencies:
> > > > - Trinidad's plugins/utils to generate stuff like the TagClass file.
> > > >
> > > > The vision:
> > > > Why this is needed ?
> > > > It is kind of hard to actually use only some "common" pieces of
> > > > Tomahawk. At least to add a custom validator, the complete jar is
> > > > needed. The vision is also to add some "common" pieces from
> > > > Trinidad/tobago to it.
> > > >
> > > > For Tomahawk this will not mean, you have to introduce a new namespace
> > > > for adding the converter/validator, the "commons-jar" can be a rt
> > > > dependency so that the TLD file is only referencing to the classes
> > > > w/in the commons.jar.
> > > >
> > > > What are you missing ?
> > > > We will compile a list into the MyFaces wiki, based on your feedback/comments
> > > >
> > > > -Bernd/Matthias
> > > >
> > >
> >
>
Re: [Proposal] Apache MyFaces commons
Posted by Cagatay Civici <ca...@gmail.com>.
Hi,
This array of modules makes my head go wwwwwwwrrrr..
Yeah mine too:)
I agree with the idea of having non rendering components in commons jar at
first. Also it'd be good if we move the overlapping features in
trinidad,tomahawk and tobago to this commons module like subform. So we
don't keep reinventing the wheel.
Cagatay
Coast Guard
On 5/4/07, Martin Marinschek <ma...@gmail.com> wrote:
>
> This array of modules makes my head go wwwwwwwrrrr..
>
> Why can't we go back to the original suggestion, and separate in a
> public API and an internal API, but in the same jar-file.
>
> org.apache.myfaces.commons.public.*
> org.apache.myfaces.commons.internal.*
>
> And what's the reason again not to have a very small set of very
> common components which don't render markup, but every component
> library needs in there? Components can be public API, just like in
> Trinidad?
>
> regards,
>
> Martin
>
> On 5/4/07, Glauco Pimentel Gomes <gl...@yahoo.com.br> wrote:
> > What do you think about a sub project called "Myfaces Modules" like
> > "Spring Modules" [1], and modules like:
> >
> > - Myfaces Converters and Validators (all, including client side);
> >
> > - Myfaces Dojo Support [2];
> >
> > - Myfaces Common Components;
> > - DataList;
> > - SaveState;
> > - SubForm;
> > - AliasBean;
> > - HtmlTag;
> > - SelectItens (Tomahawk version);
> > - JavaScript Listener;
> > - LoadBundle (Sandbox version);
> > - Focus;
> > - IfMessage;
> > - Submit on Event;
> > ...
> >
> > - Myfaces Ajax Support;
> > - Partial Page Rendering;
> > ...
> >
> > - Myfaces Common API;
> >
> > - Myfaces Shared API;
> >
> > - Myfaces Skins (future?)
> >
> > ...
> >
> > [1] https://springmodules.dev.java.net/
> > [2]
> >
> http://www.nabble.com/-Proposal--Apache-MyFaces-JAR-for-dojo-tf3687496.html
> >
> > Glauco P. Gomes
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
Re: [Proposal] Apache MyFaces commons
Posted by Martin Marinschek <ma...@gmail.com>.
This array of modules makes my head go wwwwwwwrrrr..
Why can't we go back to the original suggestion, and separate in a
public API and an internal API, but in the same jar-file.
org.apache.myfaces.commons.public.*
org.apache.myfaces.commons.internal.*
And what's the reason again not to have a very small set of very
common components which don't render markup, but every component
library needs in there? Components can be public API, just like in
Trinidad?
regards,
Martin
On 5/4/07, Glauco Pimentel Gomes <gl...@yahoo.com.br> wrote:
> What do you think about a sub project called "Myfaces Modules" like
> "Spring Modules" [1], and modules like:
>
> - Myfaces Converters and Validators (all, including client side);
>
> - Myfaces Dojo Support [2];
>
> - Myfaces Common Components;
> - DataList;
> - SaveState;
> - SubForm;
> - AliasBean;
> - HtmlTag;
> - SelectItens (Tomahawk version);
> - JavaScript Listener;
> - LoadBundle (Sandbox version);
> - Focus;
> - IfMessage;
> - Submit on Event;
> ...
>
> - Myfaces Ajax Support;
> - Partial Page Rendering;
> ...
>
> - Myfaces Common API;
>
> - Myfaces Shared API;
>
> - Myfaces Skins (future?)
>
> ...
>
> [1] https://springmodules.dev.java.net/
> [2]
> http://www.nabble.com/-Proposal--Apache-MyFaces-JAR-for-dojo-tf3687496.html
>
> Glauco P. Gomes
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [Proposal] Apache MyFaces commons
Posted by Glauco Pimentel Gomes <gl...@yahoo.com.br>.
What do you think about a sub project called "Myfaces Modules" like
"Spring Modules" [1], and modules like:
- Myfaces Converters and Validators (all, including client side);
- Myfaces Dojo Support [2];
- Myfaces Common Components;
- DataList;
- SaveState;
- SubForm;
- AliasBean;
- HtmlTag;
- SelectItens (Tomahawk version);
- JavaScript Listener;
- LoadBundle (Sandbox version);
- Focus;
- IfMessage;
- Submit on Event;
...
- Myfaces Ajax Support;
- Partial Page Rendering;
...
- Myfaces Common API;
- Myfaces Shared API;
- Myfaces Skins (future?)
...
[1] https://springmodules.dev.java.net/
[2]
http://www.nabble.com/-Proposal--Apache-MyFaces-JAR-for-dojo-tf3687496.html
Glauco P. Gomes
Re: [Proposal] Apache MyFaces commons
Posted by Adam Winer <aw...@gmail.com>.
Ahhh! :) Makes much more sense. Like you said,
I think there's already some confusion, this sets it
mostly straight. Maybe some naming is in order?
What about:
"MyFaces Basics": components/validators/filters, etc.
that users can use anywhere (== CommonComponents)
"MyFaces Commons": public APIs that we expose across
the stack (== CommonAPIs)
"MyFaces Shared": internal APIs that all the component
libraries + the impl can collaborate and depend on?
But I'm not 100% convinced that there really is a difference
between CommonComponents and CommonAPIs, or
at least enough of a difference to merit splitting them.
Mike, what about the two makes you want to split
them?
Cheers,
Adam
On 5/3/07, Mike Kienenberger <mk...@gmail.com> wrote:
> Adam,
>
> Our past discussion on "commons" was to provide JSF
> components/validators/converters that could be used in any component
> library, even if that component library is not compatible with any
> other component library (ie, tobago). I think perhaps this should be
> called CommonComponents.
>
> "Commons" as was used in this thread is not about building a component
> development API. That is a different but often-brought-up topic that
> also needs a "vision". We will want a CommonAPI to cover the area
> that Adam brought up.
>
> We should try to be clear about which we're talking about since we're
> already seeing some confusion in the thread. For example,
> AddResources would probably be a part of CommonAPI rather than
> CommonComponents.
>
> Note that MyFaces also has a "shared" module where code is shared
> between MyFaces Core and MyFaces Tomahawk.
>
> On 5/3/07, Adam Winer <aw...@gmail.com> wrote:
> > Before we do this, we have to be careful on our vision:
> > - Are we looking to define internal utilities shared among
> > Trinidad/Tomahawk/Tobago?
> > - Are we looking to define public APIs shared among these
> > projects?
> > - Are we going to have a common package name for all
> > such code?
> >
> > IMO, we should:
> > - Have no components at all in here, at least to start,
> > whether or not they render markup.
> > - Use a common package name
> > - Be very cautious and slow as we build this up, being *really*
> > sure about the APIs we're adding. This should be a foundational
> > stone for a long time.
> > - Start enforcing a public vs. private API split for real, and
> > be rigorous about when we change public APIs without
> > preserving backwards compatibility.
> >
> > Also, I don't think build dependencies belong in here, at least
> > not in terms of a packaged JAR. Whether they live in
> > a "commons" in terms of SVN locations is fine.
> >
> > -- Adam
> >
> >
> >
> > On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Greetings from the ApacheCon in Amsterdam.
> > >
> > > It was discussed a lot on the list and Bernd and I are now taking the
> > > time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
> > >
> > > Commons:
> > > -What should go into a commons JAR?
> > > Non renderKit related things like
> > > -Converters and Validators
> > > -NonFacesRequestServlet from Tobago
> > > -FacesContextFactory from Tobago to ensure a kind of common layer
> > > for doing uploads
> > > -the selectItems component from Tomahawk
> > > -what are we missing ???
> > >
> > > Build dependencies:
> > > - Trinidad's plugins/utils to generate stuff like the TagClass file.
> > >
> > > The vision:
> > > Why this is needed ?
> > > It is kind of hard to actually use only some "common" pieces of
> > > Tomahawk. At least to add a custom validator, the complete jar is
> > > needed. The vision is also to add some "common" pieces from
> > > Trinidad/tobago to it.
> > >
> > > For Tomahawk this will not mean, you have to introduce a new namespace
> > > for adding the converter/validator, the "commons-jar" can be a rt
> > > dependency so that the TLD file is only referencing to the classes
> > > w/in the commons.jar.
> > >
> > > What are you missing ?
> > > We will compile a list into the MyFaces wiki, based on your feedback/comments
> > >
> > > -Bernd/Matthias
> > >
> >
>
Re: [Proposal] Apache MyFaces commons
Posted by Mike Kienenberger <mk...@gmail.com>.
Adam,
Our past discussion on "commons" was to provide JSF
components/validators/converters that could be used in any component
library, even if that component library is not compatible with any
other component library (ie, tobago). I think perhaps this should be
called CommonComponents.
"Commons" as was used in this thread is not about building a component
development API. That is a different but often-brought-up topic that
also needs a "vision". We will want a CommonAPI to cover the area
that Adam brought up.
We should try to be clear about which we're talking about since we're
already seeing some confusion in the thread. For example,
AddResources would probably be a part of CommonAPI rather than
CommonComponents.
Note that MyFaces also has a "shared" module where code is shared
between MyFaces Core and MyFaces Tomahawk.
On 5/3/07, Adam Winer <aw...@gmail.com> wrote:
> Before we do this, we have to be careful on our vision:
> - Are we looking to define internal utilities shared among
> Trinidad/Tomahawk/Tobago?
> - Are we looking to define public APIs shared among these
> projects?
> - Are we going to have a common package name for all
> such code?
>
> IMO, we should:
> - Have no components at all in here, at least to start,
> whether or not they render markup.
> - Use a common package name
> - Be very cautious and slow as we build this up, being *really*
> sure about the APIs we're adding. This should be a foundational
> stone for a long time.
> - Start enforcing a public vs. private API split for real, and
> be rigorous about when we change public APIs without
> preserving backwards compatibility.
>
> Also, I don't think build dependencies belong in here, at least
> not in terms of a packaged JAR. Whether they live in
> a "commons" in terms of SVN locations is fine.
>
> -- Adam
>
>
>
> On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > Greetings from the ApacheCon in Amsterdam.
> >
> > It was discussed a lot on the list and Bernd and I are now taking the
> > time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
> >
> > Commons:
> > -What should go into a commons JAR?
> > Non renderKit related things like
> > -Converters and Validators
> > -NonFacesRequestServlet from Tobago
> > -FacesContextFactory from Tobago to ensure a kind of common layer
> > for doing uploads
> > -the selectItems component from Tomahawk
> > -what are we missing ???
> >
> > Build dependencies:
> > - Trinidad's plugins/utils to generate stuff like the TagClass file.
> >
> > The vision:
> > Why this is needed ?
> > It is kind of hard to actually use only some "common" pieces of
> > Tomahawk. At least to add a custom validator, the complete jar is
> > needed. The vision is also to add some "common" pieces from
> > Trinidad/tobago to it.
> >
> > For Tomahawk this will not mean, you have to introduce a new namespace
> > for adding the converter/validator, the "commons-jar" can be a rt
> > dependency so that the TLD file is only referencing to the classes
> > w/in the commons.jar.
> >
> > What are you missing ?
> > We will compile a list into the MyFaces wiki, based on your feedback/comments
> >
> > -Bernd/Matthias
> >
>
Re: [Proposal] Apache MyFaces commons
Posted by Adam Winer <aw...@gmail.com>.
Before we do this, we have to be careful on our vision:
- Are we looking to define internal utilities shared among
Trinidad/Tomahawk/Tobago?
- Are we looking to define public APIs shared among these
projects?
- Are we going to have a common package name for all
such code?
IMO, we should:
- Have no components at all in here, at least to start,
whether or not they render markup.
- Use a common package name
- Be very cautious and slow as we build this up, being *really*
sure about the APIs we're adding. This should be a foundational
stone for a long time.
- Start enforcing a public vs. private API split for real, and
be rigorous about when we change public APIs without
preserving backwards compatibility.
Also, I don't think build dependencies belong in here, at least
not in terms of a packaged JAR. Whether they live in
a "commons" in terms of SVN locations is fine.
-- Adam
On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> Greetings from the ApacheCon in Amsterdam.
>
> It was discussed a lot on the list and Bernd and I are now taking the
> time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
>
> Commons:
> -What should go into a commons JAR?
> Non renderKit related things like
> -Converters and Validators
> -NonFacesRequestServlet from Tobago
> -FacesContextFactory from Tobago to ensure a kind of common layer
> for doing uploads
> -the selectItems component from Tomahawk
> -what are we missing ???
>
> Build dependencies:
> - Trinidad's plugins/utils to generate stuff like the TagClass file.
>
> The vision:
> Why this is needed ?
> It is kind of hard to actually use only some "common" pieces of
> Tomahawk. At least to add a custom validator, the complete jar is
> needed. The vision is also to add some "common" pieces from
> Trinidad/tobago to it.
>
> For Tomahawk this will not mean, you have to introduce a new namespace
> for adding the converter/validator, the "commons-jar" can be a rt
> dependency so that the TLD file is only referencing to the classes
> w/in the commons.jar.
>
> What are you missing ?
> We will compile a list into the MyFaces wiki, based on your feedback/comments
>
> -Bernd/Matthias
>
Re: [Proposal] Apache MyFaces commons
Posted by Volker Weber <v....@inexso.de>.
Hi,
2007/5/3, Matthias Wessendorf <ma...@apache.org>:
> On 5/3/07, Mike Kienenberger <mk...@gmail.com> wrote:
> > It should also include t:saveState. Possibly t:aliasBean (havent
> > used it myself).
>
> +1
+1
>
> > Maybe verison of t:dataList (the "simple" mode) that doesn't render
> > state? This one is more of a stretch, I expect, but an enhanced
> > component iterator would be a good thing in commons.
>
> isn't that guy rendering somewhat HTML ?
should be no problem to implement a kind of forEach based on UIData if
the t:dataList
did not fit the commons requirements.
>
> > >
> > > What are you missing ?
> > > We will compile a list into the MyFaces wiki, based on your feedback/comments
There is already a wiki page according to this project:
http://wiki.apache.org/myfaces/ComponentsCommons
Regards,
Volker
> > >
> > > -Bernd/Matthias
> > >
Re: [Proposal] Apache MyFaces commons
Posted by Mike Kienenberger <mk...@gmail.com>.
And how about getting subForm into commons? I know that there's a
subForm in Trinidad, Tomahawk, and Tobago. Seems pretty "common" to
me, although I don't know if it's possible to do this one in a
non-rendering library.
Perhaps this one should be saved for Tomahawk2.
On 5/3/07, Mike Kienenberger <mk...@gmail.com> wrote:
> On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Maybe verison of t:dataList (the "simple" mode) that doesn't render
> > > state? This one is more of a stretch, I expect, but an enhanced
> > > component iterator would be a good thing in commons.
> >
> > isn't that guy rendering somewhat HTML ?
>
> In simple mode, I don't think there is anything rendered by
> t:dataList. Only the children are rendered.
>
> I think the t:dataList should be separated out into a component that
> doesn't render and a component that renders. From the facelets
> mailing list, I can tell you that there's a lot of demand for such a
> component, particularly when the ui:repeat component (the facelets
> version) doesn't do everything that t:dataList does or when it's got a
> bug (which it currently has).
>
> Personally, the three things that JSF needs are page-scoped beans
> (such as provided by t:saveState), a non-rendering iterator
> (t:dataList), and partial validation (s:subForm). It would be
> impossible to do useful work without these in my experience. You can
> fake everything else by generating the raw html yourself.
>
> I can always find another component library for generating html.
>
Re: [Proposal] Apache MyFaces commons
Posted by Mike Kienenberger <mk...@gmail.com>.
On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > Maybe verison of t:dataList (the "simple" mode) that doesn't render
> > state? This one is more of a stretch, I expect, but an enhanced
> > component iterator would be a good thing in commons.
>
> isn't that guy rendering somewhat HTML ?
In simple mode, I don't think there is anything rendered by
t:dataList. Only the children are rendered.
I think the t:dataList should be separated out into a component that
doesn't render and a component that renders. From the facelets
mailing list, I can tell you that there's a lot of demand for such a
component, particularly when the ui:repeat component (the facelets
version) doesn't do everything that t:dataList does or when it's got a
bug (which it currently has).
Personally, the three things that JSF needs are page-scoped beans
(such as provided by t:saveState), a non-rendering iterator
(t:dataList), and partial validation (s:subForm). It would be
impossible to do useful work without these in my experience. You can
fake everything else by generating the raw html yourself.
I can always find another component library for generating html.
Re: [Proposal] Apache MyFaces commons
Posted by Matthias Wessendorf <ma...@apache.org>.
On 5/3/07, Mike Kienenberger <mk...@gmail.com> wrote:
> It should also include t:saveState. Possibly t:aliasBean (havent
> used it myself).
+1
> Maybe verison of t:dataList (the "simple" mode) that doesn't render
> state? This one is more of a stretch, I expect, but an enhanced
> component iterator would be a good thing in commons.
isn't that guy rendering somewhat HTML ?
> Are the client-side validation parts of the validators going to cause
> issues with a commons library, or can just the "server-side" part of
> the validators be in commons?
first I think "only" server-side. I'd also like to see Trinidad's
client-side Converter/Validator support in a commons JAR.
>
> I haven't looked at how this was implemented.
thanks for your feedback!
-Matthias
> On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> > Greetings from the ApacheCon in Amsterdam.
> >
> > It was discussed a lot on the list and Bernd and I are now taking the
> > time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
> >
> > Commons:
> > -What should go into a commons JAR?
> > Non renderKit related things like
> > -Converters and Validators
> > -NonFacesRequestServlet from Tobago
> > -FacesContextFactory from Tobago to ensure a kind of common layer
> > for doing uploads
> > -the selectItems component from Tomahawk
> > -what are we missing ???
> >
> > Build dependencies:
> > - Trinidad's plugins/utils to generate stuff like the TagClass file.
> >
> > The vision:
> > Why this is needed ?
> > It is kind of hard to actually use only some "common" pieces of
> > Tomahawk. At least to add a custom validator, the complete jar is
> > needed. The vision is also to add some "common" pieces from
> > Trinidad/tobago to it.
> >
> > For Tomahawk this will not mean, you have to introduce a new namespace
> > for adding the converter/validator, the "commons-jar" can be a rt
> > dependency so that the TLD file is only referencing to the classes
> > w/in the commons.jar.
> >
> > What are you missing ?
> > We will compile a list into the MyFaces wiki, based on your feedback/comments
> >
> > -Bernd/Matthias
> >
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [Proposal] Apache MyFaces commons
Posted by Mike Kienenberger <mk...@gmail.com>.
It should also include t:saveState. Possibly t:aliasBean (havent
used it myself).
Maybe verison of t:dataList (the "simple" mode) that doesn't render
state? This one is more of a stretch, I expect, but an enhanced
component iterator would be a good thing in commons.
Are the client-side validation parts of the validators going to cause
issues with a commons library, or can just the "server-side" part of
the validators be in commons?
I haven't looked at how this was implemented.
On 5/3/07, Matthias Wessendorf <ma...@apache.org> wrote:
> Greetings from the ApacheCon in Amsterdam.
>
> It was discussed a lot on the list and Bernd and I are now taking the
> time to layout a "apache-myfaces-commons-[SUBSET]-VERSION.jar" file.
>
> Commons:
> -What should go into a commons JAR?
> Non renderKit related things like
> -Converters and Validators
> -NonFacesRequestServlet from Tobago
> -FacesContextFactory from Tobago to ensure a kind of common layer
> for doing uploads
> -the selectItems component from Tomahawk
> -what are we missing ???
>
> Build dependencies:
> - Trinidad's plugins/utils to generate stuff like the TagClass file.
>
> The vision:
> Why this is needed ?
> It is kind of hard to actually use only some "common" pieces of
> Tomahawk. At least to add a custom validator, the complete jar is
> needed. The vision is also to add some "common" pieces from
> Trinidad/tobago to it.
>
> For Tomahawk this will not mean, you have to introduce a new namespace
> for adding the converter/validator, the "commons-jar" can be a rt
> dependency so that the TLD file is only referencing to the classes
> w/in the commons.jar.
>
> What are you missing ?
> We will compile a list into the MyFaces wiki, based on your feedback/comments
>
> -Bernd/Matthias
>