Yep, those _ classes where meant as internal classes and never for
public API-like use.
And if I remember right, they where all package private (you know,
those weird classes that lack the access modifier ;-) in the
beginning. Didn't realize they have been changed to public... Hmm
Of course there
k
lemme work on that
(already opend an issue)
the pubic in the class was in that particular case the weired thing
here for me ;)
-M
On 11/23/06, Manfred Geiler [EMAIL PROTECTED] wrote:
Yep, those _ classes where meant as internal classes and never for
public API-like use.
And if I remember
are using RendererUtils. Which sounds to much like a util for a
renderer developer :)
But on the other hand the findNestingForm is much more related to
renderers and if we move only that function away, we have a class with
a single method.
Also why is the name starting with _ ?
Thanks,
Matthias
Hi!
_ComponentUtils to RendererUtils ?
Also why is the name starting with _ ?
I think that was to express the fact that this is an internal utils
class. Not for public use.
You know, one of the major oddities in java, you can't have package and
sub-package private methods.
Ciao,
Mario
internally for me in that case only means inside the shared;
I consider shared as an API
so a *user* of shared shouldn't use _XXX
-M
On 11/22/06, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
_ComponentUtils to RendererUtils ?
Also why is the name starting with _ ?
I think that was to
in myfaces-api we have the same;
but nobody outside of myfaces-api uses them ;)
so same should be true for shared as well...
On 11/22/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
internally for me in that case only means inside the shared;
I consider shared as an API
so a *user* of
Hi!
in myfaces-api we have the same;
but nobody outside of myfaces-api uses them ;)
so same should be true for shared as well...
I think those _ thingies were introduces before the shared comes to
live, so thats why we have them all around.
If we think this breaks our naming convention we
, why we have the findNestingForm method twice?
with the same logic.
I'd like to refactor that, if there is no real reason.
-M
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page
in the _Com.. clazz
-M
On 11/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
is there a reason, why we have the findNestingForm method twice?
with the same logic.
I'd like to refactor that, if there is no real reason.
-M
--
Matthias Wessendorf
http
[EMAIL PROTECTED] wrote:
is there a reason, why we have the findNestingForm method twice?
with the same logic.
I'd like to refactor that, if there is no real reason.
-M
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
prefer to remove the method in the _Com.. clazz
-M
On 11/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
is there a reason, why we have the findNestingForm method twice?
with the same logic.
I'd like to refactor that, if there is no real reason.
-M
--
Matthias
findNestingForm implemented twice
--
Key: MYFACES-1496
URL: http://issues.apache.org/jira/browse/MYFACES-1496
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions
created issue and assigned to me:
http://issues.apache.org/jira/browse/MYFACES-1496
I prefer to remove the method in the _Com.. clazz
-M
On 11/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
is there a reason, why we have the findNestingForm method twice?
with the same logic.
I'd
://issues.apache.org/jira/browse/MYFACES-1496
I prefer to remove the method in the _Com.. clazz
-M
On 11/17/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
is there a reason, why we have the findNestingForm method twice?
with the same logic.
I'd like to refactor that, if there is no real reason.
-M
is there a reason, why we have the findNestingForm method twice?
with the same logic.
I'd like to refactor that, if there is no real reason.
-M
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Hi devs,
since we ran into issues with some FormComponents which *extend*
UIForm, but override the Family maybe we should add an instanceof to
the findNestingForm() method ?
Currently we test if the Form is a member of the following families:
javax.faces.Form
org.apache.struts.faces.Form
True, definitely. Let's do that.
regards,
Martin
On 9/24/06, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi devs,
since we ran into issues with some FormComponents which *extend*
UIForm, but override the Family maybe we should add an instanceof to
the findNestingForm() method ?
Currently
findNestingForm() tests only against component family and against instanceof
UIForm
---
Key: MYFACES-1422
URL: http://issues.apache.org/jira/browse/MYFACES-1422
Project
maybe we should add an instanceof to
the findNestingForm() method ?
Currently we test if the Form is a member of the following families:
javax.faces.Form
org.apache.struts.faces.Form
org.apache.myfaces.trinidad.Form
oracle.adf.Form
The family org.apache.struts.faces.Form I added to day
[ http://issues.apache.org/jira/browse/MYFACES-1422?page=all ]
Matthias Weßendorf resolved MYFACES-1422.
-
Fix Version/s: 1.1.5-SNAPSHOT
Resolution: Fixed
fixed in svn
findNestingForm() tests only against component family and against
20 matches
Mail list logo
