You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Martin Marinschek <ma...@gmail.com> on 2006/06/23 10:00:03 UTC
[VOTE] Move s:form to tomahawk
Hi devs,
for the client-side validation extensions in tomahawk, we'd need an extended
form in tomahawk. Now we only have one in sandbox, but it has been around
there for a while and is pretty stable. Would it be ok to move it over, as
soon as I took care of the documentation for it? (I'll do this during the 72
hours of the vote, just want to start the vote right now so that I don't
delay Cagatay)
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> Hi Martin!
>
>> moving s:form has nothing to do with RI compatibility - we remain as
>> compatible as before.
>>
> Does this mean we ARE compatible with RI? We behave the same way as
> JSF-RI with our form/command* stuff?
> So if one uses tomahawk with JSF-RI and OUR t:form then it will work?
>
BTW, this doesnt mean that I am against the move, I just wanted to know ;-)
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> moving s:form has nothing to do with RI compatibility - we remain as
> compatible as before.
Does this mean we ARE compatible with RI? We behave the same way as
JSF-RI with our form/command* stuff?
So if one uses tomahawk with JSF-RI and OUR t:form then it will work?
Or do you mean with "as before" that we are still not compatible and -
for sure - this move do not make the situation any better.
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Sean Schofield <se...@gmail.com>.
Yes we should definitely have test cases for new components as well.
I try to add ones when I'm fixing bugs in the older components as
well.
Sean
On 7/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> I was thinking about the requirements last days, when worked with
> Shale-Test and JMock.
>
> I noticed that there are only some tests for components in Tomahawk.
> Wouldn't it be great to have a test-case as a requirement for
> promoting a component ?
>
> And of course, Mike is right in *testing* with RI and example.
>
> -Matthias
>
> On 7/14/06, Sean Schofield <se...@gmail.com> wrote:
> > I agree with Mike on both points.
> >
> > On 7/14/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > > On 7/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > > moving s:form has nothing to do with RI compatibility - we remain as
> > > > compatible as before.
> > > >
> > > > So let me reopen the vote, s:form is well documented (example wouldn't
> > > > help much), and it should be ok to move it to tomahawk.
> > >
> > > Has s:form been tested with the RI yet? (It's one of our promotion
> > > requirements.)
> > >
> > > Also, I think an example should still be provided even if it's trivial
> > > right now.
> > > Future expansion on the s:form tag may not be trivial.
> > >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: [VOTE] Move s:form to tomahawk
Posted by Sean Schofield <se...@gmail.com>.
> A component that doesn't work with both implementations is simply broken.
> Instead of relying on "help" from a JSF implementation, it should be
> redesigned to include its own help.
I don't think there would be many +1 votes for releasing new
components that depend on the MyFaces implementation. I also agree
with your earlier point about one or two components that don't work
with RI spoils the reputation/perception of the entire component set.
> Craig
Sean
Re: [VOTE] Move s:form to tomahawk
Posted by Craig McClanahan <cr...@apache.org>.
On 7/14/06, Mike Kienenberger <mk...@gmail.com> wrote:
>
> On 7/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > Deliberately releasing components that don't work with the RI does not
> seem
> > like something that will increase the market acceptance of MyFaces
> > components.
>
> Well, let's not make this more sinister than it is. There have been
> cases in the past where a tomahawk component could not function
> without "help" from the JSF implementation. These are the cases
> where something might be marked as incompatible with other
> implementations.
A component that doesn't work with both implementations is simply broken.
Instead of relying on "help" from a JSF implementation, it should be
redesigned to include its own help.
Craig
Re: [VOTE] Move s:form to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 7/14/06, Craig McClanahan <cr...@apache.org> wrote:
> Deliberately releasing components that don't work with the RI does not seem
> like something that will increase the market acceptance of MyFaces
> components.
Well, let's not make this more sinister than it is. There have been
cases in the past where a tomahawk component could not function
without "help" from the JSF implementation. These are the cases
where something might be marked as incompatible with other
implementations.
For all other components, we'd expect the test to show that it was
compatible with the RI and had been tested with it.
[And now that we've remove the MyFaces dummyforms stuff, I'm not
really sure if there's anything left that's incompatible with the RI].
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
> Who said anything about adopting Java EE 5? I'm talking about people
> considering adopting JSF 1.2. Yes, MyFaces will have such an implementation
> eventually, but if people get the impression that this group only cares
> about compatibility with their own JSF implementation, then what's the point
> of implementing a standard in the first place?
Sorry for beeing harsh. I agree on your point. He should (must) focus
on RI compatibility. To get (back) the impression that we also care
about RI. For my self I say that I use RI for testing before voting on
a Tomahawk release.
Matt
> Craig
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Craig McClanahan <cr...@apache.org>.
On 7/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> On 7/14/06, Craig McClanahan <cr...@apache.org> wrote:
> > I can tell you from years of painful experience, supporting some JSP tag
> > libraries that rendered complex output, that the golden file approach
> can be
> > really fragile and I'd never do it again :-). The problem we had is two
> > fold:
> >
> > * Some changes that are innocuous in their effect on the runtime
> > (such as changing the order of attributes generated in an element)
> > will still break the golden file. False positive error reports are
> never
> > a productivity enhancer :-).
> >
> > * If you deliberately change the output of a component, the tendency
> > of the developer is to just re-record the entire golden file, and
> forget
> > to examine whether some other bug was introduced (such as omitting
> > a child element or something). We found ourselves introducing
> > new errors when this occurred, which kind of defeats the purpose.
>
> *snip*
> This means that we are not testing the order in which attributes are
> written, which we shouldn't be testing, since order doesn't mean
> anything.
> (http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework)
>
> > Deliberately releasing components that don't work with the RI does not
> seem
> > like something that will increase the market acceptance of MyFaces
> > components. Instead, this would create (or increase) a perception that
> > MyFaces developers are not interested in compatibility. Also, given the
>
> right.
>
> > fact that the RI has a 1.2 version available and MyFaces doesn't yet, it
> > seems likely to give people a reason to consider switching away.
>
> Nope.
> Not every company is going to *swtich* to Java EE 5 only because it is
> now released. From what I learned at my last job is, that big
> companies are going to have *solid* base for their technology stack. I
> also know from a friend that they recently switched away from Java EE
> 1.2 to Java EE 1.4 (or from 2 -> 4, what ever the real name is...).
Who said anything about adopting Java EE 5? I'm talking about people
considering adopting JSF 1.2. Yes, MyFaces will have such an implementation
eventually, but if people get the impression that this group only cares
about compatibility with their own JSF implementation, then what's the point
of implementing a standard in the first place?
Craig
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Cagatay!
> Since not the form component itself but mainly the renderer is going
> to be extended and refer to the original form renderer after doing
> some script rendering, I guess t:form should work with RI as well.
After a short break where I ride my bicycle I'll come up with a
different sight on this topic.
I think its not a good idea to depend on the from tag to initialize the
client validation. I think we have to find a different solution.
Why?
The reason is simple. Think about trinidad, they also have their own
form component. Now, when every component library requires its own form
component to work, we end up in ABSOLUTELY NON INTEROPERABLE component
libraries.
This is not the basic idea of JSF, is it?
So to initialize the client validation stuff I would like to have a
separate component which renders all the required javascript.
<s:initClientValidation />
We can have one tag just before the </f:view> tag. Or - for nicely
designed application somewhere in a footer include or template.
I think there is no other way to solve this as long as there is no fine
grained spec for the form/command* stuff in JSF and a way to "replace"
the renderer with delegation (like the factory stuff)
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Just to close out the thread - the links worked for Matt now as well.
Wendy,
I was calling mvn clean install from here:
URL: https://svn.apache.org/repos/asf/myfaces/current
Basis des Projektarchivs: https://svn.apache.org/repos/asf
UUID des Projektarchivs: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 422166
Knotentyp: Verzeichnis
Plan: normal
Letzter Autor: wsmoak
Letzte ge?\195?\164nderte Rev: 417049
Letztes ?\195?\132nderungsdatum: 2006-06-25 22:09:11 +0200 (So, 25 Jun 2006)
Eigenschaften zuletzt ge?\195?\164ndert: 2006-04-17 21:06:44 +0200 (Mo, 17 Apr 2
006)
and as I said, after a run I got the myfaces impl and api files in:
..\myfaces\tomahawk\sandbox\examples\target\tomahawk-sandbox-e
xamples\WEB-INF\lib>
regards,
Martin
On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> On 7/16/06, Martin Marinschek <ma...@gmail.com> wrote:
> > That's exactly what I tested yesterday and for me, it works.
> > Interesting! Do you get any javascript errors?
>
> no
>
> > Also, I still get myfaces-api and myfaces-impl in the
> > target/app/WEB-INF/lib directory, even with a mvn clean install
> > -Djsf=ri. Could it be that there is still a dependency left somewhere?
>
> well that worked for me.
> but I only deleted the myfaces-xxx jars
> and!!!! the work folder from my uncle tomcat.
>
> > I had to clean those two libs out several times yesterday to make this work.
> >
> > regards,
> >
> > Martin
> >
> > On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > I deployed sandbox w/ RI and ran Martin's new example.
> > >
> > > I figured out two issues. Inside of that example t:commandLink is not
> > > working with the h:form AND h:commandLink is not working inside a
> > > s:form.
> > >
> > > Like:
> > >
> > > That is not working:
> > > <h:form ..>
> > > ...
> > > <t:commandLink value="test2" action="#{formBean.testAction}"/>
> > > ...
> > > </h:form>
> > >
> > > and that is not working too:
> > > <s:form ...>
> > > ...
> > > <h:commandLink value="test1" action="#{formBean.testAction}"/>
> > > ...
> > > </s:form>
> > >
> > > Regards,
> > > Matthias
> > >
> > > On 7/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > > Looking at commit log of "svn commit: r422260", I think yes.
> > > > I'll give it a try (sandbox w/ RI).
> > > >
> > > > -Matthias
> > > >
> > > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > Ok reading the end of the thread now it seems this has been addressed?
> > > > >
> > > > > Sean
> > > > >
> > > > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > > > To sum up my point:
> > > > > > > * Its nothing bad to move now and document its "not compatible to RI"
> > > > > > > * But, as soon as possible we should have a look at making form/command*
> > > > > > > RI compatible
> > > > > >
> > > > > > So do we have a definitive answer on whether this works with the RI?
> > > > > > If not, then I'm -1 for promotion. We have had too many sloppy
> > > > > > releases and confusion lately. It can be used in the sandbox just as
> > > > > > easily as it can be used in tomahawk. IMO if its not ready to work
> > > > > > with the RI then its not ready to leave the sandbox. I don't know the
> > > > > > particulars of this component but this is my general feeling about any
> > > > > > sandbox component.
> > > > > >
> > > > > > > Mario
> > > > > >
> > > > > > Sean
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Cagatay Civici <ca...@gmail.com>.
Hi,
I took the
> time to do our homework and made tomahawk and the RI fully compatible
> in all link/button/form related issues. I also added an example -
> form.jsf in the sandbox root which demonstrates this.
Great news! Also now I see why Martin has delayed his response to the
thread:)
* add the validation stuff to t:form
> * add a single tag which adds the validation stuff if one didn't use
> t:form but h:form or trinidad:form
Yes Mario, this is the optimal solution, it brings great flexibility. I
really liked the idea the RI user's can enable the client validation. Also
myfaces users do not need to do much since form is gonna take care of a lot
things. So since s:form is compatible now, we can test our client
converter&validators at sandbox with it and take a step forward later and
promote the form with our new stuff to the tomahawk. Do I get it right?
I've looked at the client converter proposal, seems nice, I'd really see the
numberconverter and the validators working together in action.
So I'll start working on the patches now.
Cagatay
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
+1 for Mario's and Cagatay's plans on how to proceed with validation
and conversion!
With this, there is also no immediate pressure to release t:form, so
we can still test a little.
regards,
Martin
On 7/16/06, Martin Marinschek <ma...@gmail.com> wrote:
> Hmm...
>
> That's exactly what I tested yesterday and for me, it works.
> Interesting! Do you get any javascript errors?
>
> Also, I still get myfaces-api and myfaces-impl in the
> target/app/WEB-INF/lib directory, even with a mvn clean install
> -Djsf=ri. Could it be that there is still a dependency left somewhere?
>
> I had to clean those two libs out several times yesterday to make this work.
>
> regards,
>
> Martin
>
> On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > I deployed sandbox w/ RI and ran Martin's new example.
> >
> > I figured out two issues. Inside of that example t:commandLink is not
> > working with the h:form AND h:commandLink is not working inside a
> > s:form.
> >
> > Like:
> >
> > That is not working:
> > <h:form ..>
> > ...
> > <t:commandLink value="test2" action="#{formBean.testAction}"/>
> > ...
> > </h:form>
> >
> > and that is not working too:
> > <s:form ...>
> > ...
> > <h:commandLink value="test1" action="#{formBean.testAction}"/>
> > ...
> > </s:form>
> >
> > Regards,
> > Matthias
> >
> > On 7/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Looking at commit log of "svn commit: r422260", I think yes.
> > > I'll give it a try (sandbox w/ RI).
> > >
> > > -Matthias
> > >
> > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > Ok reading the end of the thread now it seems this has been addressed?
> > > >
> > > > Sean
> > > >
> > > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > > To sum up my point:
> > > > > > * Its nothing bad to move now and document its "not compatible to RI"
> > > > > > * But, as soon as possible we should have a look at making form/command*
> > > > > > RI compatible
> > > > >
> > > > > So do we have a definitive answer on whether this works with the RI?
> > > > > If not, then I'm -1 for promotion. We have had too many sloppy
> > > > > releases and confusion lately. It can be used in the sandbox just as
> > > > > easily as it can be used in tomahawk. IMO if its not ready to work
> > > > > with the RI then its not ready to leave the sandbox. I don't know the
> > > > > particulars of this component but this is my general feeling about any
> > > > > sandbox component.
> > > > >
> > > > > > Mario
> > > > >
> > > > > Sean
> > > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Wendy Smoak <ws...@gmail.com>.
On 7/16/06, Martin Marinschek <ma...@gmail.com> wrote:
> Also, I still get myfaces-api and myfaces-impl in the
> target/app/WEB-INF/lib directory, even with a mvn clean install
> -Djsf=ri. Could it be that there is still a dependency left somewhere?
>
> I had to clean those two libs out several times yesterday to make this work.
In what module is this happening? (The URL from 'svn info' if possible.)
Thanks,
Wendy
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Cagatay!
> It would absolutely be excellent if h:form of myfaces is allowed to
> render the client validation scripts
No, this is no option, then a JSF-RI user has no chance at all to get
our stuff running.
> then there is no need for a t:fom or any additinal tag.
Now, that Martin made MyFaces fully RI compatible we can go the
following way (I discussed it with Martin off list, though, we are open
for comments anyway ;-) )
* add the validation stuff to t:form
* add a single tag which adds the validation stuff if one didn't use
t:form but h:form or trinidad:form
So, one can have the comfort of t:form OR use the tag, so we can provide
maximum flexibility.
> That sounds also good to me Mario, to play with it a little longer
> until these compatibility issues are hopefully resolved. We can also
> take care of the client converter stuff there too. Also for now,
> onkeypress type validations can be integrated.
Yes, please, lets bring together client-validation and converter in
sandbox - we can use the convertNumber to test our stuff and then move
it to tomahawk - there is no pressure of time, is it?
I'll try to do more work for the converter during the next week, maybe
starting tomorrow. Did you look at the converter interface proposal?
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Cagatay Civici <ca...@gmail.com>.
Hi,
Mario: My whole idea is to reduce the necessary effort of myfaces users in
order to enable client side validation. My aim was to avoid additional tags
and use a context param to turn on/off client validation. Also with an
extended form renderer, decorate the onsubmit event and render scripts.
My initial experiments like;
http://jsf-comp.sourceforge.net/components/clientvalidators/index.html
and the shale's validation use a seperate component to render the client
script and users need to set the onsubmit event of the form manually to
check for validation. I always tried to avoid this but in the end I've
realized it is inevitable since people need to replace h:form with t:form.
It would absolutely be excellent if h:form of myfaces is allowed to render
the client validation scripts, then there is no need for a t:fom or any
additinal tag. Anyway, I've also done some work in sandbox some time ago;
http://www.irian.at/cagatay-validation-sandbox/home.jsf
That sounds also good to me Mario, to play with it a little longer until
these compatibility issues are hopefully resolved. We can also take care of
the client converter stuff there too. Also for now, onkeypress type
validations can be integrated.
Matthias: Yes, the project I'm working for uses ibm jsf, not my choice for
sure:)
Regards,
Cagatay
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Mike,
I submitted the bug reports.
1) I believe the problem is even broader than you think: currently,
IMHO, the RI clean fields method will only work for the first link in
every form, cause only for this first link the clearing javascript is
rendered. Now if you want to render the script for more than one link,
you're stuck - there is no way to collect them all while renderering
in a standard compliant way right now! MyFaces has the same problem,
and solves it in a proprietory way. A tree walker would be great here,
then we could just walk through all components in the encodeEnd of the
form...
2) As to the problem you pointed out: What I did is make the clear...
function of MyFaces look the same as the RI one from the function call
- this solves the compatibility problem between MyFaces and the RI,
but it doesn't solve the underlying problem you pointed out in your
report.
I believe there is not much of a solution, if we don't provide
something like a submit functionality for non-link components in the
standard itself, enabled by an attribute on the component. Trinidad
has it...
Although, it might be possible to hook into the submit method of the
form itself in a javascript way - wouldn't be easy, though. We can't
just overwrite onsubmit, the users need this for other stuff as well!
regards,
Martin
On 7/15/06, Michael Youngstrom <yo...@gmail.com> wrote:
> >Along
> > with a nice bug I'd be happy to point out to someone interested to fix
> > it - I believe that the clear script rendered in the RI only works for
> > the first link.
> >
> > To put it this way: if I hadn't put a hack into the extended form
> > renderer, the RI buttons in version 1.1. and 1.2. would never work
> > with a not RI-form at all! (forget my commit message, I indicated that
> > in 1.2 this was fixed, but obviously it wasn't)
>
> A bug report would be greatly appreciated. :)
>
> https://javaserverfaces.dev.java.net/servlets/ProjectIssues
>
> On a side note I've been struggling with issues regarding commandLink
> clear function interoperability. Strangly enough I just started a
> thread on the RI dev mailing list about this topic moments before I
> read this message from you. Though I'm talking more as a spec issue
> rather than an implementation issue I'd still appreciate input from
> the tomahawk team on this topic since you've all worked a lot with
> developing cross implementation components. Perhaps there are some
> workarounds for this issue that I'm unaware of?
>
> https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=871
>
> Mike
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Michael Youngstrom <yo...@gmail.com>.
>Along
> with a nice bug I'd be happy to point out to someone interested to fix
> it - I believe that the clear script rendered in the RI only works for
> the first link.
>
> To put it this way: if I hadn't put a hack into the extended form
> renderer, the RI buttons in version 1.1. and 1.2. would never work
> with a not RI-form at all! (forget my commit message, I indicated that
> in 1.2 this was fixed, but obviously it wasn't)
A bug report would be greatly appreciated. :)
https://javaserverfaces.dev.java.net/servlets/ProjectIssues
On a side note I've been struggling with issues regarding commandLink
clear function interoperability. Strangly enough I just started a
thread on the RI dev mailing list about this topic moments before I
read this message from you. Though I'm talking more as a spec issue
rather than an implementation issue I'd still appreciate input from
the tomahawk team on this topic since you've all worked a lot with
developing cross implementation components. Perhaps there are some
workarounds for this issue that I'm unaware of?
https://javaserverfaces.dev.java.net/servlets/ReadMsg?list=dev&msgNo=871
Mike
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 7/15/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Martin!
> > I took the
> > time to do our homework and made tomahawk and the RI fully compatible
> > in all link/button/form related issues. I also added an example -
> > form.jsf in the sandbox root which demonstrates this.
> Congratulations Martin - you tha man :-D
thx
http://www.yourethemannowdog.com/
> Now, who said we didn't take compatibility seriously ;-)
> This is a big step forward for tomahawk!
>
>
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Martin!
> I took the
> time to do our homework and made tomahawk and the RI fully compatible
> in all link/button/form related issues. I also added an example -
> form.jsf in the sandbox root which demonstrates this.
Congratulations Martin - you tha man :-D
Now, who said we didn't take compatibility seriously ;-)
This is a big step forward for tomahawk!
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Ok,
first off: Mario was entirely right - sorry. In any case, I took the
time to do our homework and made tomahawk and the RI fully compatible
in all link/button/form related issues. I also added an example -
form.jsf in the sandbox root which demonstrates this.
With regards to compatibility problems and MyFaces, I would be very,
very silent if I was a member of the RI team. I've seen some
interesting compatibility problems in the RI source code today. Along
with a nice bug I'd be happy to point out to someone interested to fix
it - I believe that the clear script rendered in the RI only works for
the first link.
To put it this way: if I hadn't put a hack into the extended form
renderer, the RI buttons in version 1.1. and 1.2. would never work
with a not RI-form at all! (forget my commit message, I indicated that
in 1.2 this was fixed, but obviously it wasn't)
so, FWIW, this is my final starting call: let's vote now. It can only
be much better with compatibility issues after what I've done today.
regards,
Martin
P.S.: Cagatay, Mario is entirely right. I'd love to have an optional
initializing component. But only optional, the extended form taking
care of this would still be cool.
On 7/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> On 7/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > To sum up my point:
> > > * Its nothing bad to move now and document its "not compatible to RI"
> >
> > If I need to vote on it, you'll get my -1
> >
> > > * But, as soon as possible we should have a look at making form/command*
> > > RI compatible
> > >
> > > However, Cagatay, can't we play a little bit longer in the sandbox with
> > > your stuff and also the clientConverter thingy?
> >
> > That sounds bad. Nothing wrong with sandbox.
>
> sounds *not* bad; sorry ...
>
> > > Maybe in the meantime we find some volunteer for the problem above. At
> > > least one who can check the s:form in a JSF-RI environment would be very
> > > nice.
> >
> > I'll play with that guy tomorrow. Btw. Cagatay, I think you guys are
> > using the RI too, right?
> > Or are you using IBM ? Just interested. B/c your FacesTrace pictures :)
> > I think I saw some com.sun.faces.*** clazzes on the stack.
> >
> > -Matthias
> >
> > > Ciao,
> > > Mario
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 7/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > To sum up my point:
> > * Its nothing bad to move now and document its "not compatible to RI"
>
> If I need to vote on it, you'll get my -1
>
> > * But, as soon as possible we should have a look at making form/command*
> > RI compatible
> >
> > However, Cagatay, can't we play a little bit longer in the sandbox with
> > your stuff and also the clientConverter thingy?
>
> That sounds bad. Nothing wrong with sandbox.
sounds *not* bad; sorry ...
> > Maybe in the meantime we find some volunteer for the problem above. At
> > least one who can check the s:form in a JSF-RI environment would be very
> > nice.
>
> I'll play with that guy tomorrow. Btw. Cagatay, I think you guys are
> using the RI too, right?
> Or are you using IBM ? Just interested. B/c your FacesTrace pictures :)
> I think I saw some com.sun.faces.*** clazzes on the stack.
>
> -Matthias
>
> > Ciao,
> > Mario
> >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
> To sum up my point:
> * Its nothing bad to move now and document its "not compatible to RI"
If I need to vote on it, you'll get my -1
> * But, as soon as possible we should have a look at making form/command*
> RI compatible
>
> However, Cagatay, can't we play a little bit longer in the sandbox with
> your stuff and also the clientConverter thingy?
That sounds bad. Nothing wrong with sandbox.
> Maybe in the meantime we find some volunteer for the problem above. At
> least one who can check the s:form in a JSF-RI environment would be very
> nice.
I'll play with that guy tomorrow. Btw. Cagatay, I think you guys are
using the RI too, right?
Or are you using IBM ? Just interested. B/c your FacesTrace pictures :)
I think I saw some com.sun.faces.*** clazzes on the stack.
-Matthias
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 7/16/06, Martin Marinschek <ma...@gmail.com> wrote:
> That's exactly what I tested yesterday and for me, it works.
> Interesting! Do you get any javascript errors?
no
> Also, I still get myfaces-api and myfaces-impl in the
> target/app/WEB-INF/lib directory, even with a mvn clean install
> -Djsf=ri. Could it be that there is still a dependency left somewhere?
well that worked for me.
but I only deleted the myfaces-xxx jars
and!!!! the work folder from my uncle tomcat.
> I had to clean those two libs out several times yesterday to make this work.
>
> regards,
>
> Martin
>
> On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > I deployed sandbox w/ RI and ran Martin's new example.
> >
> > I figured out two issues. Inside of that example t:commandLink is not
> > working with the h:form AND h:commandLink is not working inside a
> > s:form.
> >
> > Like:
> >
> > That is not working:
> > <h:form ..>
> > ...
> > <t:commandLink value="test2" action="#{formBean.testAction}"/>
> > ...
> > </h:form>
> >
> > and that is not working too:
> > <s:form ...>
> > ...
> > <h:commandLink value="test1" action="#{formBean.testAction}"/>
> > ...
> > </s:form>
> >
> > Regards,
> > Matthias
> >
> > On 7/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Looking at commit log of "svn commit: r422260", I think yes.
> > > I'll give it a try (sandbox w/ RI).
> > >
> > > -Matthias
> > >
> > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > Ok reading the end of the thread now it seems this has been addressed?
> > > >
> > > > Sean
> > > >
> > > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > > To sum up my point:
> > > > > > * Its nothing bad to move now and document its "not compatible to RI"
> > > > > > * But, as soon as possible we should have a look at making form/command*
> > > > > > RI compatible
> > > > >
> > > > > So do we have a definitive answer on whether this works with the RI?
> > > > > If not, then I'm -1 for promotion. We have had too many sloppy
> > > > > releases and confusion lately. It can be used in the sandbox just as
> > > > > easily as it can be used in tomahawk. IMO if its not ready to work
> > > > > with the RI then its not ready to leave the sandbox. I don't know the
> > > > > particulars of this component but this is my general feeling about any
> > > > > sandbox component.
> > > > >
> > > > > > Mario
> > > > >
> > > > > Sean
> > > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Hmm...
That's exactly what I tested yesterday and for me, it works.
Interesting! Do you get any javascript errors?
Also, I still get myfaces-api and myfaces-impl in the
target/app/WEB-INF/lib directory, even with a mvn clean install
-Djsf=ri. Could it be that there is still a dependency left somewhere?
I had to clean those two libs out several times yesterday to make this work.
regards,
Martin
On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> I deployed sandbox w/ RI and ran Martin's new example.
>
> I figured out two issues. Inside of that example t:commandLink is not
> working with the h:form AND h:commandLink is not working inside a
> s:form.
>
> Like:
>
> That is not working:
> <h:form ..>
> ...
> <t:commandLink value="test2" action="#{formBean.testAction}"/>
> ...
> </h:form>
>
> and that is not working too:
> <s:form ...>
> ...
> <h:commandLink value="test1" action="#{formBean.testAction}"/>
> ...
> </s:form>
>
> Regards,
> Matthias
>
> On 7/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > Looking at commit log of "svn commit: r422260", I think yes.
> > I'll give it a try (sandbox w/ RI).
> >
> > -Matthias
> >
> > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > Ok reading the end of the thread now it seems this has been addressed?
> > >
> > > Sean
> > >
> > > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > > To sum up my point:
> > > > > * Its nothing bad to move now and document its "not compatible to RI"
> > > > > * But, as soon as possible we should have a look at making form/command*
> > > > > RI compatible
> > > >
> > > > So do we have a definitive answer on whether this works with the RI?
> > > > If not, then I'm -1 for promotion. We have had too many sloppy
> > > > releases and confusion lately. It can be used in the sandbox just as
> > > > easily as it can be used in tomahawk. IMO if its not ready to work
> > > > with the RI then its not ready to leave the sandbox. I don't know the
> > > > particulars of this component but this is my general feeling about any
> > > > sandbox component.
> > > >
> > > > > Mario
> > > >
> > > > Sean
> > > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
I deployed sandbox w/ RI and ran Martin's new example.
I figured out two issues. Inside of that example t:commandLink is not
working with the h:form AND h:commandLink is not working inside a
s:form.
Like:
That is not working:
<h:form ..>
...
<t:commandLink value="test2" action="#{formBean.testAction}"/>
...
</h:form>
and that is not working too:
<s:form ...>
...
<h:commandLink value="test1" action="#{formBean.testAction}"/>
...
</s:form>
Regards,
Matthias
On 7/15/06, Matthias Wessendorf <ma...@apache.org> wrote:
> Looking at commit log of "svn commit: r422260", I think yes.
> I'll give it a try (sandbox w/ RI).
>
> -Matthias
>
> On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > Ok reading the end of the thread now it seems this has been addressed?
> >
> > Sean
> >
> > On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > > To sum up my point:
> > > > * Its nothing bad to move now and document its "not compatible to RI"
> > > > * But, as soon as possible we should have a look at making form/command*
> > > > RI compatible
> > >
> > > So do we have a definitive answer on whether this works with the RI?
> > > If not, then I'm -1 for promotion. We have had too many sloppy
> > > releases and confusion lately. It can be used in the sandbox just as
> > > easily as it can be used in tomahawk. IMO if its not ready to work
> > > with the RI then its not ready to leave the sandbox. I don't know the
> > > particulars of this component but this is my general feeling about any
> > > sandbox component.
> > >
> > > > Mario
> > >
> > > Sean
> > >
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
Looking at commit log of "svn commit: r422260", I think yes.
I'll give it a try (sandbox w/ RI).
-Matthias
On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> Ok reading the end of the thread now it seems this has been addressed?
>
> Sean
>
> On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > > To sum up my point:
> > > * Its nothing bad to move now and document its "not compatible to RI"
> > > * But, as soon as possible we should have a look at making form/command*
> > > RI compatible
> >
> > So do we have a definitive answer on whether this works with the RI?
> > If not, then I'm -1 for promotion. We have had too many sloppy
> > releases and confusion lately. It can be used in the sandbox just as
> > easily as it can be used in tomahawk. IMO if its not ready to work
> > with the RI then its not ready to leave the sandbox. I don't know the
> > particulars of this component but this is my general feeling about any
> > sandbox component.
> >
> > > Mario
> >
> > Sean
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Sean Schofield <se...@gmail.com>.
Ok reading the end of the thread now it seems this has been addressed?
Sean
On 7/15/06, Sean Schofield <se...@gmail.com> wrote:
> > To sum up my point:
> > * Its nothing bad to move now and document its "not compatible to RI"
> > * But, as soon as possible we should have a look at making form/command*
> > RI compatible
>
> So do we have a definitive answer on whether this works with the RI?
> If not, then I'm -1 for promotion. We have had too many sloppy
> releases and confusion lately. It can be used in the sandbox just as
> easily as it can be used in tomahawk. IMO if its not ready to work
> with the RI then its not ready to leave the sandbox. I don't know the
> particulars of this component but this is my general feeling about any
> sandbox component.
>
> > Mario
>
> Sean
>
Re: [VOTE] Move s:form to tomahawk
Posted by Sean Schofield <se...@gmail.com>.
> To sum up my point:
> * Its nothing bad to move now and document its "not compatible to RI"
> * But, as soon as possible we should have a look at making form/command*
> RI compatible
So do we have a definitive answer on whether this works with the RI?
If not, then I'm -1 for promotion. We have had too many sloppy
releases and confusion lately. It can be used in the sandbox just as
easily as it can be used in tomahawk. IMO if its not ready to work
with the RI then its not ready to leave the sandbox. I don't know the
particulars of this component but this is my general feeling about any
sandbox component.
> Mario
Sean
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi Cagatay!
> Since not the form component itself but mainly the renderer is going
> to be extended and refer to the original form renderer after doing
> some script rendering, I guess t:form should work with RI as well.
The sandbox form renderer do not use delegation, but uses inheritance.
This means that the tomahawk form uses the MyFaces form render "engine"
then. There is nothing bad with this, if our form renderer behaves in a
RI compatible way, but .... is this the case?
Previously I was told (from the users) that this is NOT the case for the
command* guys, and this might also be true for our form too - I wonder
why Martin didn't respond to this topic?
Hey - Martin, whats up?? ;-)
I already realized that we want the move to tomahawk to allow your
validation stuff ;-), but this also means that this validation stuff
requires the use of t:form what a JSF-RI user cant do. So all this new
and sexy stuff cant be used by this group.
Remember, tomahawk should be a component library and should work in any
JSF compatible environment, at least that was our goal.
To sum up my point:
* Its nothing bad to move now and document its "not compatible to RI"
* But, as soon as possible we should have a look at making form/command*
RI compatible
However, Cagatay, can't we play a little bit longer in the sandbox with
your stuff and also the clientConverter thingy?
Maybe in the meantime we find some volunteer for the problem above. At
least one who can check the s:form in a JSF-RI environment would be very
nice.
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Cagatay Civici <ca...@gmail.com>.
Hi,
I'm not familiar with the compatibility issues but I wonder Martin's
response to this discussion since he is the originator.
Today me and Martin talked about moving the s:form to the tomahawk because
of the client validation requirement.
Since not the form component itself but mainly the renderer is going to be
extended and refer to the original form renderer after doing some script
rendering, I guess t:form should work with RI as well.
Regards,
Cagatay
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
On 7/14/06, Craig McClanahan <cr...@apache.org> wrote:
> I can tell you from years of painful experience, supporting some JSP tag
> libraries that rendered complex output, that the golden file approach can be
> really fragile and I'd never do it again :-). The problem we had is two
> fold:
>
> * Some changes that are innocuous in their effect on the runtime
> (such as changing the order of attributes generated in an element)
> will still break the golden file. False positive error reports are never
> a productivity enhancer :-).
>
> * If you deliberately change the output of a component, the tendency
> of the developer is to just re-record the entire golden file, and forget
> to examine whether some other bug was introduced (such as omitting
> a child element or something). We found ourselves introducing
> new errors when this occurred, which kind of defeats the purpose.
*snip*
This means that we are not testing the order in which attributes are
written, which we shouldn't be testing, since order doesn't mean
anything.
(http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework)
> Deliberately releasing components that don't work with the RI does not seem
> like something that will increase the market acceptance of MyFaces
> components. Instead, this would create (or increase) a perception that
> MyFaces developers are not interested in compatibility. Also, given the
right.
> fact that the RI has a 1.2 version available and MyFaces doesn't yet, it
> seems likely to give people a reason to consider switching away.
Nope.
Not every company is going to *swtich* to Java EE 5 only because it is
now released. From what I learned at my last job is, that big
companies are going to have *solid* base for their technology stack. I
also know from a friend that they recently switched away from Java EE
1.2 to Java EE 1.4 (or from 2 -> 4, what ever the real name is...).
For usecase like "I have this unused webapp with five pages or six" I
think it is ok to switch to a *newer* technology stack (java ee 5).
But big companies, don't like to play a paying beta-tester. But the
last year showed that lot's of these *fast* apps are developed with
Rails etc.
For MyFaces, we started right now the development of JavaServer Faces
1.2 and asked for a TCK.
-Matthias
> The best approach is to make the build system so powerful that running your
> entire test suite against either the MyFaces or RI implementations is a
> single command line parameter. Wendy's already done that for Shale (so we
> have no excuses for the framework not supporting both :-), and I'm sure it
> can be done for the component libraries too.
>
> > Ciao,
> > Mario
> >
> >
> Craig
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
yes :)
On 7/16/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > >
> > > "mvn install " vs. "mvn install -Djsf=ri"
> >
> > I just ran "mvn install -Djsf=ri" and the result I had
> > jsf-api/jsf-impl and MyFaces-1.1.5-SNAPSHOT in my WEB-INF/lib.
> >
> > Any ideas?
>
> Make sure to 'mvn clean' when you switch implementations. That's the
> only trick to this. :)
>
> You probably still had target/appname/WEB-INF/lib there from a prior
> build with MyFaces.
>
> --
> Wendy
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Wendy Smoak <ws...@gmail.com>.
On 7/16/06, Matthias Wessendorf <ma...@apache.org> wrote:
> >
> > "mvn install " vs. "mvn install -Djsf=ri"
>
> I just ran "mvn install -Djsf=ri" and the result I had
> jsf-api/jsf-impl and MyFaces-1.1.5-SNAPSHOT in my WEB-INF/lib.
>
> Any ideas?
Make sure to 'mvn clean' when you switch implementations. That's the
only trick to this. :)
You probably still had target/appname/WEB-INF/lib there from a prior
build with MyFaces.
--
Wendy
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
>
> "mvn install " vs. "mvn install -Djsf=ri"
I just ran "mvn install -Djsf=ri" and the result I had
jsf-api/jsf-impl and MyFaces-1.1.5-SNAPSHOT in my WEB-INF/lib.
Any ideas?
> --
> Wendy
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Wendy Smoak <ws...@gmail.com>.
On 7/14/06, Craig McClanahan <cr...@apache.org> wrote:
> The best approach is to make the build system so powerful that running your
> entire test suite against either the MyFaces or RI implementations is a
> single command line parameter. Wendy's already done that for Shale (so we
> have no excuses for the framework not supporting both :-), and I'm sure it
> can be done for the component libraries too.
Not me. :) As I recall, the idea came from here originally, was
enhanced by someone on the maven users list, and then was contributed
back to MyFaces.
"mvn install " vs. "mvn install -Djsf=ri"
Maven has some work yet to do as far as supporting integration testing
easily. Right now the best approach is to establish a separate module
for the integration tests.
If you're going to release components that only work with MyFaces, I'd
suggest putting them in a separate jar. If there's something really
cool that's not possible with the RI, then that's a selling point for
MyFaces... but releasing a "Tomahawk" that doesn't work with the RI
does not sound like a good idea to me.
--
Wendy
Re: [VOTE] Move s:form to tomahawk
Posted by Craig McClanahan <cr...@apache.org>.
On 7/14/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
> >> I noticed that there are only some tests for components in Tomahawk.
> >> Wouldn't it be great to have a test-case as a requirement for
> >> promoting a component ?
> > Sure, if we can decide what reasonable test cases are.
> I would like to see more test-cases too, but not by using mock tests. I
> think for component testing its way too much work and error prone after
> refactoring.
> I was told (thanks to matze ;-) ) that trinidad uses so called
> gold-files - it compares the resulting html with an "known-to-be-good"
> (=gold) html file,
I can tell you from years of painful experience, supporting some JSP tag
libraries that rendered complex output, that the golden file approach can be
really fragile and I'd never do it again :-). The problem we had is two
fold:
* Some changes that are innocuous in their effect on the runtime
(such as changing the order of attributes generated in an element)
will still break the golden file. False positive error reports are never
a productivity enhancer :-).
* If you deliberately change the output of a component, the tendency
of the developer is to just re-record the entire golden file, and forget
to examine whether some other bug was introduced (such as omitting
a child element or something). We found ourselves introducing
new errors when this occurred, which kind of defeats the purpose.
though, what I really would like to see for component
> testing is something like htmlunit (http://htmlunit.sourceforge.net/)
> which allows some basic javascript testing too.
Shale's test framework includes support for exactly this scenario (using
HtmlUnit). Many of the "system integration" tests in Shale's use cases
example use this to evaluate the actual output ... very convenient, because
HtmlUnit gives you back a DOM of the output, and you can test your
assertions as needed.
That being said, the behavior of a JSF component and renderer combination is
complex enough that you probably want both unit tests on the individual
methods and integration tests on the overall output.
>> And of course, Mike is right in *testing* with RI and example.
> >
> > Note that I don't think that the component necessarily has to work
> > with the RI to be promoted. But the documentation for the component
> > should state whether it's expected to work with the RI or not, which
> > would be determined by the testing.
> This is my point too, we should document if a tag breaks RI
> compatibility. As far as I know, only the form and command* stuff will
> break RI compatibility and - as long as there is no spec for this, its
> hard to make it "any JSF" compatible - we can act as RI and so we can be
> RI compatible, but as long as there is no spec for the parameter passing
> stuff we cant make it "any JSF" compatible.
> However, whats the case why we didnt change our classes to be at least
> RI compatible?
> Thomas and Martin wanted to look at it, but didnt came up with a
> solution - is there something fundamental which prevents it, or is it
> simply a matter of time?
Deliberately releasing components that don't work with the RI does not seem
like something that will increase the market acceptance of MyFaces
components. Instead, this would create (or increase) a perception that
MyFaces developers are not interested in compatibility. Also, given the
fact that the RI has a 1.2 version available and MyFaces doesn't yet, it
seems likely to give people a reason to consider switching away.
The best approach is to make the build system so powerful that running your
entire test suite against either the MyFaces or RI implementations is a
single command line parameter. Wendy's already done that for Shale (so we
have no excuses for the framework not supporting both :-), and I'm sure it
can be done for the component libraries too.
Ciao,
> Mario
>
> Craig
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
> > Adam brought this to the wiki
> > http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework
>
> Right, and from what I've glanced over, this is similar in function to
> what I proposed a year ago. It was pointed out at the time that this
> didn't really let you test ajax/javascript, though.
I also like using Shale/Jmock
http://tinyurl.com/p3qcn
-Matt
>
> ---------- Forwarded message ----------
> From: Mike Kienenberger <mk...@gmail.com>
> Date: Aug 17, 2005 10:56 AM
> Subject: Renderkit for testing
> To: MyFaces User mailing list <us...@myfaces.apache.org>
>
>
> Has anyone given any thought to a renderkit designed for testing?
>
> Perhaps it would "render" a Map entry for every UIOutput subclass with
> the id as the key and the component value as the value during
> encoding, and reverse the process for decoding.
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 7/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > I would like to see more test-cases too, but not by using mock tests. I
> > think for component testing its way too much work and error prone after
> > refactoring.
> > I was told (thanks to matze ;-) ) that trinidad uses so called
> > gold-files - it compares the resulting html with an "known-to-be-good"
> > (=gold) html file, though, what I really would like to see for component
> > testing is something like htmlunit (http://htmlunit.sourceforge.net/)
> > which allows some basic javascript testing too.
>
> Adam brought this to the wiki
> http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework
Right, and from what I've glanced over, this is similar in function to
what I proposed a year ago. It was pointed out at the time that this
didn't really let you test ajax/javascript, though.
---------- Forwarded message ----------
From: Mike Kienenberger <mk...@gmail.com>
Date: Aug 17, 2005 10:56 AM
Subject: Renderkit for testing
To: MyFaces User mailing list <us...@myfaces.apache.org>
Has anyone given any thought to a renderkit designed for testing?
Perhaps it would "render" a Map entry for every UIOutput subclass with
the id as the key and the component value as the value during
encoding, and reverse the process for decoding.
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
> I would like to see more test-cases too, but not by using mock tests. I
> think for component testing its way too much work and error prone after
> refactoring.
> I was told (thanks to matze ;-) ) that trinidad uses so called
> gold-files - it compares the resulting html with an "known-to-be-good"
> (=gold) html file, though, what I really would like to see for component
> testing is something like htmlunit (http://htmlunit.sourceforge.net/)
> which allows some basic javascript testing too.
Adam brought this to the wiki
http://wiki.apache.org/myfaces/Trinidad_RenderKit_test_framework
> >> And of course, Mike is right in *testing* with RI and example.
> >
> > Note that I don't think that the component necessarily has to work
> > with the RI to be promoted. But the documentation for the component
> > should state whether it's expected to work with the RI or not, which
> > would be determined by the testing.
> This is my point too, we should document if a tag breaks RI
> compatibility. As far as I know, only the form and command* stuff will
> break RI compatibility and - as long as there is no spec for this, its
> hard to make it "any JSF" compatible - we can act as RI and so we can be
> RI compatible, but as long as there is no spec for the parameter passing
> stuff we cant make it "any JSF" compatible.
> However, whats the case why we didnt change our classes to be at least
> RI compatible?
> Thomas and Martin wanted to look at it, but didnt came up with a
> solution - is there something fundamental which prevents it, or is it
> simply a matter of time?
>
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
>> I noticed that there are only some tests for components in Tomahawk.
>> Wouldn't it be great to have a test-case as a requirement for
>> promoting a component ?
> Sure, if we can decide what reasonable test cases are.
I would like to see more test-cases too, but not by using mock tests. I
think for component testing its way too much work and error prone after
refactoring.
I was told (thanks to matze ;-) ) that trinidad uses so called
gold-files - it compares the resulting html with an "known-to-be-good"
(=gold) html file, though, what I really would like to see for component
testing is something like htmlunit (http://htmlunit.sourceforge.net/)
which allows some basic javascript testing too.
>> And of course, Mike is right in *testing* with RI and example.
>
> Note that I don't think that the component necessarily has to work
> with the RI to be promoted. But the documentation for the component
> should state whether it's expected to work with the RI or not, which
> would be determined by the testing.
This is my point too, we should document if a tag breaks RI
compatibility. As far as I know, only the form and command* stuff will
break RI compatibility and - as long as there is no spec for this, its
hard to make it "any JSF" compatible - we can act as RI and so we can be
RI compatible, but as long as there is no spec for the parameter passing
stuff we cant make it "any JSF" compatible.
However, whats the case why we didnt change our classes to be at least
RI compatible?
Thomas and Martin wanted to look at it, but didnt came up with a
solution - is there something fundamental which prevents it, or is it
simply a matter of time?
Ciao,
Mario
Re: [VOTE] Move s:form to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 7/14/06, Matthias Wessendorf <ma...@apache.org> wrote:
> I was thinking about the requirements last days, when worked with
> Shale-Test and JMock.
>
> I noticed that there are only some tests for components in Tomahawk.
> Wouldn't it be great to have a test-case as a requirement for
> promoting a component ?
Sure, if we can decide what reasonable test cases are.
> And of course, Mike is right in *testing* with RI and example.
Note that I don't think that the component necessarily has to work
with the RI to be promoted. But the documentation for the component
should state whether it's expected to work with the RI or not, which
would be determined by the testing.
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
I was thinking about the requirements last days, when worked with
Shale-Test and JMock.
I noticed that there are only some tests for components in Tomahawk.
Wouldn't it be great to have a test-case as a requirement for
promoting a component ?
And of course, Mike is right in *testing* with RI and example.
-Matthias
On 7/14/06, Sean Schofield <se...@gmail.com> wrote:
> I agree with Mike on both points.
>
> On 7/14/06, Mike Kienenberger <mk...@gmail.com> wrote:
> > On 7/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > > moving s:form has nothing to do with RI compatibility - we remain as
> > > compatible as before.
> > >
> > > So let me reopen the vote, s:form is well documented (example wouldn't
> > > help much), and it should be ok to move it to tomahawk.
> >
> > Has s:form been tested with the RI yet? (It's one of our promotion
> > requirements.)
> >
> > Also, I think an example should still be provided even if it's trivial
> > right now.
> > Future expansion on the s:form tag may not be trivial.
> >
>
--
Matthias Wessendorf
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Sean Schofield <se...@gmail.com>.
I agree with Mike on both points.
On 7/14/06, Mike Kienenberger <mk...@gmail.com> wrote:
> On 7/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> > moving s:form has nothing to do with RI compatibility - we remain as
> > compatible as before.
> >
> > So let me reopen the vote, s:form is well documented (example wouldn't
> > help much), and it should be ok to move it to tomahawk.
>
> Has s:form been tested with the RI yet? (It's one of our promotion
> requirements.)
>
> Also, I think an example should still be provided even if it's trivial
> right now.
> Future expansion on the s:form tag may not be trivial.
>
Re: [VOTE] Move s:form to tomahawk
Posted by Mike Kienenberger <mk...@gmail.com>.
On 7/14/06, Martin Marinschek <ma...@gmail.com> wrote:
> moving s:form has nothing to do with RI compatibility - we remain as
> compatible as before.
>
> So let me reopen the vote, s:form is well documented (example wouldn't
> help much), and it should be ok to move it to tomahawk.
Has s:form been tested with the RI yet? (It's one of our promotion
requirements.)
Also, I think an example should still be provided even if it's trivial
right now.
Future expansion on the s:form tag may not be trivial.
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Sorry for my confusion,
moving s:form has nothing to do with RI compatibility - we remain as
compatible as before.
So let me reopen the vote, s:form is well documented (example wouldn't
help much), and it should be ok to move it to tomahawk.
docu: myfaces\tomahawk\sandbox\core\src\site\xdoc\form.xml
regards,
Martin
On 6/23/06, Matthias Wessendorf <ma...@apache.org> wrote:
> if it breaks RI based app
> -1
>
> if not +0
>
>
>
> On 6/23/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> >
> > +1
> >
> > However, we should adapt our form/commandLink/commandButton stuff to
> > make its output compatible with RI real soon.
> >
> > Ciao,
> > Mario
> >
> >
>
>
> --
> Matthias Wessendorf
> Aechterhoek 18
> 48282 Emsdetten
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Matthias Wessendorf <ma...@apache.org>.
if it breaks RI based app
-1
if not +0
On 6/23/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi!
>
> +1
>
> However, we should adapt our form/commandLink/commandButton stuff to
> make its output compatible with RI real soon.
>
> Ciao,
> Mario
>
>
--
Matthias Wessendorf
Aechterhoek 18
48282 Emsdetten
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: [VOTE] Move s:form to tomahawk
Posted by Martin Marinschek <ma...@gmail.com>.
Yeah, right. Let me first look into that, then I'll restart the vote.
regards,
Martin
On 6/23/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
>
> +1
>
> However, we should adapt our form/commandLink/commandButton stuff to
> make its output compatible with RI real soon.
>
> Ciao,
> Mario
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: [VOTE] Move s:form to tomahawk
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
+1
However, we should adapt our form/commandLink/commandButton stuff to
make its output compatible with RI real soon.
Ciao,
Mario