[
http://issues.apache.org/jira/browse/TOMAHAWK-516?page=comments#action_12435832
]
Cosma Colanicchia commented on TOMAHAWK-516:
Sorry guys, sources for my test projects was on a pc that now is in assistance,
and my schedule
[
http://issues.apache.org/jira/browse/TOMAHAWK-516?page=comments#action_12421993
]
Cosma Colanicchia commented on TOMAHAWK-516:
The findNestingForm refactoring has already been coded and committed in the
meantime by Martin
It seems to me that both ways lead to inheritance :)
I think that an interface should be used, especially if the *only*
goal of an abstract base class would be defining those two abstract
methods.
This is also more flexible because multiple interfaces inheritance is
allowed: suppose you have a
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
Okay, but 1 and 4 returns an UIForm, while 2 returns an UIComponent.
How to deal with this?
2006/7/6, Mario Ivankovits [EMAIL PROTECTED]:
Hi Cosma!
Maybe we can do some cleanout, removing the RenderUtils.findParentForm
and making SubFormRenderer and HtmlTabbedPaneRenderer use the
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 [EMAIL PROTECTED]:
Cosma Colanicchia schrieb
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
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,
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
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 [EMAIL PROTECTED]:
Hello,
I'm trying to use the Tomahawk JSCookMenu in my
MyFaces/Trinidad/Facelets project
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
Okey, done.
Here is the patched patch :)
Cosma
2006/7/5, Cosma Colanicchia [EMAIL PROTECTED]:
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
[ http://issues.apache.org/jira/browse/TOMAHAWK-516?page=all ]
Cosma Colanicchia updated TOMAHAWK-516:
---
Status: Patch Available (was: Open)
JSCookMenu problems in a Trinidad project
-
Key
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,
that the real sources are now
being downloaded.. thank you Wendy.
Cosma
2006/6/29, Wendy Smoak [EMAIL PROTECTED]:
On 6/28/06, Cosma Colanicchia [EMAIL PROTECTED] wrote:
I have done a fresh checkout of latest myfaces, and just installed
maven 2.0.4. I cant build myfaces, mvn install gives me this error
Hi,
I have done a fresh checkout of latest myfaces, and just installed
maven 2.0.4. I cant build myfaces, mvn install gives me this error:
D:\Sviluppo\myfacesmvn install
[INFO] Scanning for projects...
[INFO]
[ERROR] FATAL
It would be better to have a context initialization parameter to
enable this behaviour.. sometimes it is expected to drop request
scoped stuff on redirects :). BTW, nice idea..
Some days ago I was thinking about something similar but selective,
with an extended navigation rule syntax allowing
I had in mind something like this:
navigation-rule
from-view-id*/from-view-id
navigation-case
from-outcomegotoEditPerson/from-outcome
to-view-id/person/edit.jspx(personId)/to-view-id
navigation-case
/navigation-rule
See the to-view-id: that view declares that it wants a personId
Note that I was thinking more about request parameters than
request-scoped objects.. not really the same thing :-)
Bye
Cosma
2006/6/23, Cosma Colanicchia [EMAIL PROTECTED]:
I had in mind something like this:
navigation-rule
from-view-id*/from-view-id
navigation-case
from
Have you tried to set the forceIdIndexFormula of t:dataTable to a proper field?
Cosma
2006/6/15, Daniele Bernardini [EMAIL PROTECTED]:
Hi people,
maybe this is old news for you but I stumbled upon a problem with input
fields inside t:columns. Namely the generated id is equal across the
whole
I put a vote on JSF issue #179.. maybe other java.net registered users
here could do the same :-)
Cosma
2006/6/14, Matthias Weßendorf (JIRA) dev@myfaces.apache.org:
[
http://issues.apache.org/jira/browse/MYFACES-1103?page=comments#action_12416126
]
Matthias Weßendorf commented on
21 matches
Mail list logo
