JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Hello,

I'm trying to use the Tomahawk JSCookMenu in my
MyFaces/Trinidad/Facelets project, but I have some troubles. Note that
I use an "home.jspx" page with an iframe. I want my menu on the outer
page, and links opened in the iframe.

First attemp:
Simply put the <t:jscookMenu> inside my <af:form
targetFrame="iframeContent">. Problem: all the dummy stuff is
generated, probably because the <af:form> doesn't get recognized.

Second attemp:
Tried to use <h:form> instead of <af:form>. Just a try, because the
<h:form> doesn't give me a chance to set a target.. anyway this
doesn't work, a javascript error "dummyForm.elements.jscook_action has
no properties" occours.

Third attemp:
Used <h:form> but put <t:jscookMenu> outside of this, this half works:
another dummyform is generated with the "_self" target, and the page
isn't opened in the iframe.

Fourth attemp:
Same as 3td but using <af:form>. Also same result..

I use latest 1.1.5 snapshot of MyFaces (updated and rebuilt
yesterday). I noted that also MyFacesHack.js cmItemMouseUp function
looks for a form with the "_self" target..


Any help on this?
Cosma

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Yes, finally I used that approach (don't add the FacesContext
attribute and get it with the static method) in RenderUtils, in
HtmlJSCookMenuRenderer and in SubFormRenderer.

I'm doing some test (thought more testing will be required), then I'll
upload the new patch in JIRA.

Ciao
Cosma

2006/7/6, Mario Ivankovits <ma...@ops.co.at>:
> Hi Cosma!
> > About RenderUtils I'm in doubt.. I changed the return type and added
> > the FacesContex argument, so its really a "new" method, I think that
> > it is useless to mark it as deprecated.. also because it actually does
> > a thin wrapping for the _ComponentUtils method, as it extracts the
> > UIComponent from the FormInfo object.
> Why did you add the FacesContext argument? You can get it throug
> getCurrentInstance() too.
> However, shared is not that important for me as we always release it as
> a copy within the released artifact itself.
> If someone outside of tomahawk use shared he/she might have problems,
> though, this method might not be that widely used.
>
> >
> > I'm for leaving it without deprecation.. note that the original method
> > is actually gone :)
> Ok.
>
>
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cosma!
> About RenderUtils I'm in doubt.. I changed the return type and added
> the FacesContex argument, so its really a "new" method, I think that
> it is useless to mark it as deprecated.. also because it actually does
> a thin wrapping for the _ComponentUtils method, as it extracts the
> UIComponent from the FormInfo object.
Why did you add the FacesContext argument? You can get it throug
getCurrentInstance() too.
However, shared is not that important for me as we always release it as
a copy within the released artifact itself.
If someone outside of tomahawk use shared he/she might have problems,
though, this method might not be that widely used.

>
> I'm for leaving it without deprecation.. note that the original method
> is actually gone :)
Ok.


Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

About RenderUtils I'm in doubt.. I changed the return type and added
the FacesContex argument, so its really a "new" method, I think that
it is useless to mark it as deprecated.. also because it actually does
a thin wrapping for the _ComponentUtils method, as it extracts the
UIComponent from the FormInfo object.

I'm for leaving it without deprecation.. note that the original method
is actually gone :)

Ciao
Cosma



2006/7/6, Mario Ivankovits <ma...@ops.co.at>:
> Hi Cosma!
> > Please correct if I'm wrong: references to shared class must be done
> > using the "shared" package for classes in shared package itself, and
> > using "shared_tomahawk" from the external tomahawk classes?
> Exactly!
>
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cosma!
> Please correct if I'm wrong: references to shared class must be done
> using the "shared" package for classes in shared package itself, and
> using "shared_tomahawk" from the external tomahawk classes?
Exactly!

Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Ok, I'm doing it right now.

Please correct if I'm wrong: references to shared class must be done
using the "shared" package for classes in shared package itself, and
using "shared_tomahawk" from the external tomahawk classes?


2006/7/6, Mario Ivankovits <ma...@ops.co.at>:
> Cosma Colanicchia schrieb:
> > Okay, but 1 and 4 returns an UIForm, while 2 returns an UIComponent.
> Ok, I overlooked it, Sorry!
>
> 1 is in "shared", so you safely can change the return type as we bundle
> a renamed copy of shared with tomahawk.
> and as 4 is also only used by the class itself it should be safe to
> change its return type too.
> I think, we can change both to UIComponent and add the same notice to
> the javadoc.
>
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Cosma Colanicchia schrieb:
> Okay, but 1 and 4 returns an UIForm, while 2 returns an UIComponent.
Ok, I overlooked it, Sorry!

1 is in "shared", so you safely can change the return type as we bundle
a renamed copy of shared with tomahawk.
and as 4 is also only used by the class itself it should be safe to
change its return type too.
I think, we can change both to UIComponent and add the same notice to
the javadoc.

Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Okay, but 1 and 4 returns an UIForm, while 2 returns an UIComponent.

How to deal with this?


2006/7/6, Mario Ivankovits <ma...@ops.co.at>:
> Hi Cosma!
>
> > Maybe we can do some cleanout, removing the RenderUtils.findParentForm
> > and making SubFormRenderer and HtmlTabbedPaneRenderer use the
> > _ComponentUtils method? What do you think about this?
> Yes, great work.
>
> So lets cleanup this stuff, but maybe without deleting those methods. We
> have to start to provide better backward compatibility.
> So please delegate within the methods in question to _ComponentUtils and
> mark them as @deprecated. For a later major release of MyFaces we can
> remove them.
>
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cosma!

> Maybe we can do some cleanout, removing the RenderUtils.findParentForm
> and making SubFormRenderer and HtmlTabbedPaneRenderer use the
> _ComponentUtils method? What do you think about this?
Yes, great work.

So lets cleanup this stuff, but maybe without deleting those methods. We
have to start to provide better backward compatibility.
So please delegate within the methods in question to _ComponentUtils and
mark them as @deprecated. For a later major release of MyFaces we can
remove them.

Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Okay, I've done a little research about those findNestingForm /
findParentForm methods. An implementation is actually provided by:

1) public static UIForm findParentForm(...) in shared.renderkit.RenderUtils
2) public static FormInfo findNestingForm(...) in shared.util._ComponentUtils
3) public static FormInfo findNestingForm(...)  in
renderkit.html.util.DummyFormUtils
4) protected UIForm findParentForm(...) in custom.subform.SubFormRenderer

Usage notes:

1) RenderUtils.findParentForm
This method seems to be only called by HtmlTabbedPaneRenderer object,
which, anyway, doesn't care about the type of the returned object,
only check for null value.

2) _ComponentUtils.findNestingForm
This method is invoked by the objects:
  - HtmlButtonRendererBase
  - HtmlLinkRendererBase
  - AjaxDecodePhaseListener
  - DummyFormUtils
And none of the these seems to need a cast to UIForm, they only ask
the name to FormInfo or use the UIComponent interface.

3) DummyFormUtils.findNestingForm
This method is a wrapper for the _ComponentUtils one, which creates
and return a dummy form if another one isn't already there, and that
the SubFormRenderer one is used only by itself, and implemented in the
same way of the RenderUtils one.
It is used by the objects:
  - HtmlCollapsiblePanelRenderer
  - HtmlTreeImageCommandLinkRenderer
  - HtmlButtonRenderer
  - ExtendedHtmlButtonRenderer
  - ExtendedHtmlLinkRenderer
None of them do any UIForm cast. Some of these class simply override
the superclass findNestingForm to call the DummyFormUtils instead of
the _ComponentUtils implementation.

4) SubFormRenderer.findParentForm
This is only used by the same class, its implemented in a similar way
of RenderUtils, and does not actually need the returned object to be
an UIForm (it call an UIComponent interface method).

I'm not sure I've found *every* usage of
_ComponentUtils.findNestingForm, but for the great majrority of them I
think that it is safe to return a Trinidad form.

Maybe we can do some cleanout, removing the RenderUtils.findParentForm
and making SubFormRenderer and HtmlTabbedPaneRenderer use the
_ComponentUtils method? What do you think about this?

Ciao
Cosma

2006/7/5, Mario Ivankovits <ma...@ops.co.at>:
> Hi Cosma!
> > Thank for your review Mario,
> No problem ;-)
>
> > using findNestingForm may be good, but I don't know if it is used
> > elsewhere. Maybe other objects "rely" on the component returned to be
> > an UIForm?
> Could you please check this, e.g. a cast to UIForm will fail.
> But if this is not the case, I think its best to change this method and
> add a note to the javadoc that it is not necessarily true that the
> returned component is a UIForm.
>
> Thanks!
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cosma!
> Thank for your review Mario,
No problem ;-)

> using findNestingForm may be good, but I don't know if it is used
> elsewhere. Maybe other objects "rely" on the component returned to be
> an UIForm?
Could you please check this, e.g. a cast to UIForm will fail.
But if this is not the case, I think its best to change this method and
add a note to the javadoc that it is not necessarily true that the
returned component is a UIForm.

Thanks!
Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Thank for your review Mario,

using findNestingForm may be good, but I don't know if it is used
elsewhere. Maybe other objects "rely" on the component returned to be
an UIForm? I went with a conservative approach. Moreover, the original
code itself didn't make use of that utility method.

Anyway, if you think that using that findNestingForm is a better way,
I have no problem adapting the code. Just let me know, I created an
issue on JIRA and I'm about to upload the patch there.

Ciao
Cosma


2006/7/5, Mario Ivankovits <ma...@ops.co.at>:
> Hi Cosma!
> > Okey, done.
> > Here is the patched patch :)
> Ok, fine, but, wouldnt it be best to change the
> org.apache.myfaces.shared.util._ComponentUtils.findNestingForm to work
> with trinidad too and use this in HtmlJSCookMenuRenderer.java? Just an idea.
>
> Everything else looks fine to me.
>
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cosma!
> Okey, done.
> Here is the patched patch :)
Ok, fine, but, wouldnt it be best to change the
org.apache.myfaces.shared.util._ComponentUtils.findNestingForm to work
with trinidad too and use this in HtmlJSCookMenuRenderer.java? Just an idea.

Everything else looks fine to me.

Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Okey, done.
Here is the patched patch :)


Cosma


2006/7/5, Cosma Colanicchia <co...@gmail.com>:
> Hi Mario,
>
> thanks for the good observation. Trinidad's CoreForm uses the family
> "org.apache.myfaces.adf.Form", while UIForm is "javax.faces.Form". It
> is much better to look at this property instead of using instanceof or
> class name. I'm modifying the code right now.
>
> Ciao
> Cosma
>
>
> 2006/7/5, Mario Ivankovits <ma...@ops.co.at>:
> > Hi Cosma!
> > > 1) The class HtmlJSCookMenuRenderer tries to find the parent form
> > > searching for an UIForm component, but the Trinidad CoreForm doesn't
> > > extend UIForm. This cause the the dummyform stuff rendered in the
> > > page.
> > >
> > > 2) Using either <af:form> or <h:form>, calling
> > > addHiddenCommandParameter on HtmlFormRendererBase doesn't seem to
> > > work, and the jscook hidden field isn't rendered on the form, causing
> > > a javascript error when trying to use the menu. This is probably
> > > caused by the Trinidad renderer used insted of the MyFaces one.
> > In both cases, try to use the component family to determine if this is a
> > form component.
> > Not sure which family trinidad uses, but this is the right way to do it.
> >
> > See: org.apache.myfaces.shared.util._ComponentUtils.findNestingForm
> >
> > Ciao,
> > Mario
> >
> >
>

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

Hi Mario,

thanks for the good observation. Trinidad's CoreForm uses the family
"org.apache.myfaces.adf.Form", while UIForm is "javax.faces.Form". It
is much better to look at this property instead of using instanceof or
class name. I'm modifying the code right now.

Ciao
Cosma


2006/7/5, Mario Ivankovits <ma...@ops.co.at>:
> Hi Cosma!
> > 1) The class HtmlJSCookMenuRenderer tries to find the parent form
> > searching for an UIForm component, but the Trinidad CoreForm doesn't
> > extend UIForm. This cause the the dummyform stuff rendered in the
> > page.
> >
> > 2) Using either <af:form> or <h:form>, calling
> > addHiddenCommandParameter on HtmlFormRendererBase doesn't seem to
> > work, and the jscook hidden field isn't rendered on the form, causing
> > a javascript error when trying to use the menu. This is probably
> > caused by the Trinidad renderer used insted of the MyFaces one.
> In both cases, try to use the component family to determine if this is a
> form component.
> Not sure which family trinidad uses, but this is the right way to do it.
>
> See: org.apache.myfaces.shared.util._ComponentUtils.findNestingForm
>
> Ciao,
> Mario
>
>

Re: JSCookMenu, dummy form and Trinidad problems

[Mario Ivankovits <ma...@ops.co.at>]

Hi Cosma!
> 1) The class HtmlJSCookMenuRenderer tries to find the parent form
> searching for an UIForm component, but the Trinidad CoreForm doesn't
> extend UIForm. This cause the the dummyform stuff rendered in the
> page.
>
> 2) Using either <af:form> or <h:form>, calling
> addHiddenCommandParameter on HtmlFormRendererBase doesn't seem to
> work, and the jscook hidden field isn't rendered on the form, causing
> a javascript error when trying to use the menu. This is probably
> caused by the Trinidad renderer used insted of the MyFaces one.
In both cases, try to use the component family to determine if this is a
form component.
Not sure which family trinidad uses, but this is the right way to do it.

See: org.apache.myfaces.shared.util._ComponentUtils.findNestingForm

Ciao,
Mario

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

I found two problems using jscookmenu and Trinidad:

1) The class HtmlJSCookMenuRenderer tries to find the parent form
searching for an UIForm component, but the Trinidad CoreForm doesn't
extend UIForm. This cause the the dummyform stuff rendered in the
page.

2) Using either <af:form> or <h:form>, calling
addHiddenCommandParameter on HtmlFormRendererBase doesn't seem to
work, and the jscook hidden field isn't rendered on the form, causing
a javascript error when trying to use the menu. This is probably
caused by the Trinidad renderer used insted of the MyFaces one.

To solve problem 1), I modified the HtmlJSCookMenuRenderer.java in
order to recognize also the <af:form> component as a parent form. I
used getClass().getName() instead of an instanceof for the comparison
in order to avoid a compile-time dependency.

For problem 2), I haven't found a way to add an hidden field using the
Trinidad form renderer.. maybe it is possible to add a child
inputHidden component to the parent form dinamically, but I don't know
how to set its "name" attribute and I'm not sure that, in that stage,
it will be actually rendered. So I modified the MyFacesHack.js to add
the hidden field to the DOM when it is missing. I tried the code in
IE6 and FireFox, but it shoud work also with IE5.

I have attached a patch file, can any committer take a look?

Thank you
Cosma


2006/7/5, Cosma Colanicchia <co...@gmail.com>:
> Hello,
>
> I'm trying to use the Tomahawk JSCookMenu in my
> MyFaces/Trinidad/Facelets project, but I have some troubles. Note that
> I use an "home.jspx" page with an iframe. I want my menu on the outer
> page, and links opened in the iframe.
>
> First attemp:
> Simply put the <t:jscookMenu> inside my <af:form
> targetFrame="iframeContent">. Problem: all the dummy stuff is
> generated, probably because the <af:form> doesn't get recognized.
>
> Second attemp:
> Tried to use <h:form> instead of <af:form>. Just a try, because the
> <h:form> doesn't give me a chance to set a target.. anyway this
> doesn't work, a javascript error "dummyForm.elements.jscook_action has
> no properties" occours.
>
> Third attemp:
> Used <h:form> but put <t:jscookMenu> outside of this, this half works:
> another dummyform is generated with the "_self" target, and the page
> isn't opened in the iframe.
>
> Fourth attemp:
> Same as 3td but using <af:form>. Also same result..
>
> I use latest 1.1.5 snapshot of MyFaces (updated and rebuilt
> yesterday). I noted that also MyFacesHack.js cmItemMouseUp function
> looks for a form with the "_self" target..
>
>
> Any help on this?
> Cosma
>

Re: JSCookMenu, dummy form and Trinidad problems

[Cosma Colanicchia <co...@gmail.com>]

I found two problems using jscookmenu and Trinidad:

1) The class HtmlJSCookMenuRenderer tries to find the parent form
searching for an UIForm component, but the Trinidad CoreForm doesn't
extend UIForm. This cause the the dummyform stuff rendered in the
page.

2) Using either <af:form> or <h:form>, calling
addHiddenCommandParameter on HtmlFormRendererBase doesn't seem to
work, and the jscook hidden field isn't rendered on the form, causing
a javascript error when trying to use the menu. This is probably
caused by the Trinidad renderer used insted of the MyFaces one.

To solve problem 1), I modified the HtmlJSCookMenuRenderer.java in
order to recognize also the <af:form> component as a parent form. I
used getClass().getName() instead of an instanceof for the comparison
in order to avoid a compile-time dependency.

For problem 2), I haven't found a way to add an hidden field using the
Trinidad form renderer.. maybe it is possible to add a child
inputHidden component to the parent form dinamically, but I don't know
how to set its "name" attribute and I'm not sure that, in that stage,
it will be actually rendered. So I modified the MyFacesHack.js to add
the hidden field to the DOM when it is missing. I tried the code in
IE6 and FireFox, but it shoud work also with IE5.

I have attached a patch file, can any committer take a look?

Thank you
Cosma


2006/7/5, Cosma Colanicchia <co...@gmail.com>:
> Hello,
>
> I'm trying to use the Tomahawk JSCookMenu in my
> MyFaces/Trinidad/Facelets project, but I have some troubles. Note that
> I use an "home.jspx" page with an iframe. I want my menu on the outer
> page, and links opened in the iframe.
>
> First attemp:
> Simply put the <t:jscookMenu> inside my <af:form
> targetFrame="iframeContent">. Problem: all the dummy stuff is
> generated, probably because the <af:form> doesn't get recognized.
>
> Second attemp:
> Tried to use <h:form> instead of <af:form>. Just a try, because the
> <h:form> doesn't give me a chance to set a target.. anyway this
> doesn't work, a javascript error "dummyForm.elements.jscook_action has
> no properties" occours.
>
> Third attemp:
> Used <h:form> but put <t:jscookMenu> outside of this, this half works:
> another dummyform is generated with the "_self" target, and the page
> isn't opened in the iframe.
>
> Fourth attemp:
> Same as 3td but using <af:form>. Also same result..
>
> I use latest 1.1.5 snapshot of MyFaces (updated and rebuilt
> yesterday). I noted that also MyFacesHack.js cmItemMouseUp function
> looks for a form with the "_self" target..
>
>
> Any help on this?
> Cosma
>