OK, I wont ask you to rehash the discussion ;-), I'll have to dig out
the thread. Thanks for the pointer.
On 22-Feb-06, at 7:53 PM, sean schofield (JIRA) wrote:
[ http://issues.apache.org/jira/browse/TOMAHAWK-155?
page=comments#action_12367453 ]
sean schofield commented on TOMAHAWK-155:
Hi,
Just for info, I'm using from start another htmleditor http://www.xinha.org
in myfaces. So naming them editorhtml2 is not a good idea.. but you
should define how myfaces will integrate "external" custom components..
Regards
Sean Schofield wrote:
Please no more '2' components. Seriou
[
http://issues.apache.org/jira/browse/TOMAHAWK-2?page=comments#action_12367472 ]
Adam Winer commented on TOMAHAWK-2:
---
Check out the IndentingResponseWriter class in oracle.adfinternal.view.faces.io
in the ADF Faces source code drop. Once the ADF Faces i
On Wed, 2006-02-22 at 19:49 -0500, Sean Schofield wrote:
> In response to #1 I would say we do not need to be in the business of
> ensuring developers can rely on our public API's. From my perspective
> we are in the business of providing a JSF implementation and a series
> of components and addon
On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> In response to #1 I would say we do not need to be in the business of
> ensuring developers can rely on our public API's. From my perspective
> we are in the business of providing a JSF implementation and a series
> of components and addons f
[
http://issues.apache.org/jira/browse/TOMAHAWK-155?page=comments#action_12367465
]
Simon Kitching commented on TOMAHAWK-155:
-
Re my previous comment entry: sorry, it was Werner Punz who made that comment,
in reply to Laurie.
> Move ExtensionsFilt
[
http://issues.apache.org/jira/browse/TOMAHAWK-155?page=comments#action_12367464
]
Simon Kitching commented on TOMAHAWK-155:
-
Laurie Harper noted on the email list that he's against this idea, and would
prefer to see a "phase listener based" appro
[ http://issues.apache.org/jira/browse/MYFACES-1149?page=all ]
updated MYFACES-1149:
--
> StateUtils has a static inializer that calls FacesContext.getCurrentInstance()
> --
>
> Key: MY
NullPointerException from HtmlRendererUtils first time after logging into a
servlet
---
Key: MYFACES-1151
URL: http://issues.apache.org/jira/browse/MYFACES-1151
Project: MyFaces Core
Typ
hehe, intentional lazyness, sort of ;-)
no offence, though
Sean Schofield schrieb:
@Werner: You should comment in the JIRA issue so we have your thoughts
on record all in one spot.
Sean
Bad idea the extension filter is a major pain for the users,
I would love to see to get rid of it for a pha
@Werner: You should comment in the JIRA issue so we have your thoughts
on record all in one spot.
Sean
> Bad idea the extension filter is a major pain for the users,
> I would love to see to get rid of it for a phase listener
> based approach ;-)
>
>
[
http://issues.apache.org/jira/browse/TOMAHAWK-155?page=comments#action_12367453
]
sean schofield commented on TOMAHAWK-155:
-
One issue here is that commons is not really something that we are ready to
promote as an independent API. If you read t
In response to #1 I would say we do not need to be in the business of
ensuring developers can rely on our public API's. From my perspective
we are in the business of providing a JSF implementation and a series
of components and addons for use in any JSF implementation.
I can see a situation where
fixed, thanks for pointing it out
Dennis Byrne schrieb:
s:effect has a bunch of attributes with true , is
this intentional?
Dennis Byrne
-Original Message-
From: Werner Punz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 04:21 PM
To: dev@myfaces.apache.org
Subject: ef
Laurie Harper (JIRA) schrieb:
Move ExtensionsFilter to commons so it can be reused outside Tomahawk
-
Key: TOMAHAWK-155
URL: http://issues.apache.org/jira/browse/TOMAHAWK-155
Project: MyFaces Tomahawk
No...
I will fix that asap
Dennis Byrne schrieb:
s:effect has a bunch of attributes with true , is
this intentional?
Dennis Byrne
-Original Message-
From: Werner Punz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 04:21 PM
To: dev@myfaces.apache.org
Subject: effects fa
Mike Kienenberger schrieb:
If I get some free time (hah!), I'll take a look at creating a sandbox
component for it since I'm using it. There's nothing much to it
other than outputing the example code we came up with, is there? And
probably calling AddResource to inline the javascript. If I
I'm puzzled here - is the TCK *really* asserting that this converter ID
is the wrong value?
This is clearly a bug in the RI, and the TCK should be asserting
the correct value, not covering up the RI bug much less forcing
MyFaces to have the same bug!
-- Adam
On 2/22/06, Dennis Byrne <[EMAIL PR
Mike Kienenberger wrote:
On 2/22/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
Maybe it would make sense to move Tomahawk's AddResources / Filter based
stuff into commons so it can be re-used across Tomahawk, ADFF, Tobago
and other component libraries?
I don't see any reason why we can't move t
Move ExtensionsFilter to commons so it can be reused outside Tomahawk
-
Key: TOMAHAWK-155
URL: http://issues.apache.org/jira/browse/TOMAHAWK-155
Project: MyFaces Tomahawk
Type: Task
Reporter: Lau
Ok you are right, anyway, name it as you wish, just implement the tag ;-)
Mike Kienenberger schrieb:
I think the "front-end" of the component name should state its functionality.
The "back-end" would distinquish between different implementations.
That makes it easier for end-users to find what
If I get some free time (hah!), I'll take a look at creating a sandbox
component for it since I'm using it. There's nothing much to it
other than outputing the example code we came up with, is there? And
probably calling AddResource to inline the javascript. If I have
time, I can at least get
s:effect has a bunch of attributes with true , is
this intentional?
Dennis Byrne
>-Original Message-
>From: Werner Punz [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, February 22, 2006 04:21 PM
>To: dev@myfaces.apache.org
>Subject: effects fade now 100 pro dojo
>
>Upfront warning, due to e
Matthias Wessendorf schrieb:
On 2/22/06, Werner Punz <[EMAIL PROTECTED]> wrote:
Yes, but we have to add it as a htmledit2 or so, I would not
remove the old component for now (the dojo one also has bugs but
not as many as the other one)
but would set it to deprecated use htmledit2 instead or so.
I think the "front-end" of the component name should state its functionality.
The "back-end" would distinquish between different implementations.
That makes it easier for end-users to find what they need.
I'm unlikely to go looking for components just because they're
dojo-based, but I'm likely to
Werner Punz wrote:
Laurie Harper schrieb:
The Tomahawk components 'inject' Javascript file references into the
section of the response by using a filter to buffer and
post-process the response. I'm assuming ADF Faces has some mechanism for
injecting Javascript too, but I can't seem to track
Sean Schofield schrieb:
Please no more '2' components. Seriously. We need to consider
retiring old components and just replacing them. If users want to
keep using the old component that is their porogative.
Mike, can you explain how the current version does not require
javascript? Its hard t
Upfront warning, due to enforced circumstances, I am moving the effects
fade now towards dojo, the old FAT (Fade Anything Technique) code is not
removed from the component, the component is way less intrusive now with
the new dojo code.
the FAT code will be removed from the trunk tomorrow, sin
On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Mike, can you explain how the current version does not require
> javascript? Its hard to imagine a component like this working without
> it. I'm new to this component so pardon my ignorance.
> On 2/22/06, Mike Kienenberger <[EMAIL PROTECTED
On 2/22/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> Maybe it would make sense to move Tomahawk's AddResources / Filter based
> stuff into commons so it can be re-used across Tomahawk, ADFF, Tobago
> and other component libraries?
I don't see any reason why we can't move that stuff into commons
On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> Please no more '2' components. Seriously. We need to consider
> retiring old components and just replacing them. If users want to
> keep using the old component that is their porogative.
hehe
http://tinyurl.com/nutug
>
> Mike, can you ex
Mike, thanks for the link. Yes, I'm familiar with the AddResources stuff
in Tomahawk, but was looking for the equivalent functionality in ADF
Faces so I can inter-operate with either.
L.
Mike Kienenberger wrote:
Have you looked at this?
http://wiki.apache.org/myfaces/External_Resources
On
Please no more '2' components. Seriously. We need to consider
retiring old components and just replacing them. If users want to
keep using the old component that is their porogative.
Mike, can you explain how the current version does not require
javascript? Its hard to imagine a component like
Adam Winer wrote:
Laurie,
We use a Scriptlet API down in :
oracle.adfinternal.view.faces.renderkit.core.xhtml.jsLibs
... the basic gist of which is that a Renderer can say
"hey, I need function foo()", and the Scriptlet API
figures out whether that means importing a lib, or
writing out an i
I'd prefer htmlEditDojo rather than htmlEdit2. Actually, the status
quo isn't all that horrible for end-users (of which I am now one).
I'd much rather see a component without the need for javascript, but
now that the current situation is documented on the wiki, it's
certainly usable. When we
On 2/22/06, Werner Punz <[EMAIL PROTECTED]> wrote:
> Yes, but we have to add it as a htmledit2 or so, I would not
> remove the old component for now (the dojo one also has bugs but
> not as many as the other one)
> but would set it to deprecated use htmledit2 instead or so.
+1 since *old* html edi
Yes, but we have to add it as a htmledit2 or so, I would not
remove the old component for now (the dojo one also has bugs but
not as many as the other one)
but would set it to deprecated use htmledit2 instead or so.
But for now we need a tag for the component the status quo is not
acceptible for
I'll remove it back to impl. ok?
On 2/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> ah, I see... ok, yes. there is no standard way for doing this right now.
>
> thanks for pointing it out!
>
> On 2/22/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > No compile issue, but a functional: T
On 2/22/06, Adam Winer <[EMAIL PROTECTED]> wrote:
Definitely. I think we need to extract a few issues here,and consider them separately.(1) Do we need to be in the practice of identifying APIs that external developers can depend on, and are not subject to
change. If so, how?(2) Do we consider
ah, I see... ok, yes. there is no standard way for doing this right now.
thanks for pointing it out!
On 2/22/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> No compile issue, but a functional: The MyFaces impl sets a request
> scope flag during the Lifecylce. Without this flag both methods in
> P
>Ups, sorry! I just thought it is a easy change as the field CONVERTER_ID
>will never be used.
>Do the TCK test directly check this field?
This comes up often. Is there any way to incorporate the TCK into the build
process?
Dennis Byrne
No compile issue, but a functional: The MyFaces impl sets a request
scope flag during the Lifecylce. Without this flag both methods in
PortletUtil always return false.
Manfred
On 2/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> damn... pressed send by accident
>
> The *beast* has the fo
[
http://issues.apache.org/jira/browse/TOMAHAWK-2?page=comments#action_12367391 ]
Matthias Weßendorf commented on TOMAHAWK-2:
---
any updates, regarding "fixing vs. removing" PRETTY_HTML ?
> PRETTY_HTML option is not being universally honored
> -
Hi!
> As far as I remember, we ran into some issue with the right field...
>
> Can you remove it (the right one) and add some javadoc on that.
> JSF 1.2 has been fixed. I think there is a Jira ticket on that...
>
Ok, I reverted my change - even if its really odd to have to do it ;-)
---
Mario
Werner,
there are some tickets in jira regarding the html editor component.
Will it be better to used dojo for this? And REMOVE the old component
?
Thoughts?
--
Matthias Wessendorf
Zülpicher Wall 12, 239
50674 Köln
http://www.wessendorf.net
mwessendorf-at-gmail-dot-com
As far as I remember, we ran into some issue with the right field...
Can you remove it (the right one) and add some javadoc on that.
JSF 1.2 has been fixed. I think there is a Jira ticket on that...
On 2/22/06, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
> Bruno Aranda schrieb:
> > We used the
Definitely. I think we need to extract a few issues here,
and consider them separately.
(1) Do we need to be in the practice of identifying APIs that
external developers can depend on, and are not subject to
change. If so, how?
(2) Do we consider Tomahawk, Tobago, and ADF as purely
intern
[
http://issues.apache.org/jira/browse/TOMAHAWK-51?page=comments#action_12367390
]
Werner Punz commented on TOMAHAWK-51:
-
This is a work in progress which partially will make it into 1.1.2.
As we move towards dojo the problem will go away, due to the fa
damn... pressed send by accident
The *beast* has the following import statements
import javax.faces.context.FacesContext;
import javax.portlet.RenderResponse;
so, it needs JSF API and PORTLET API
no MyFaces stuff needed ;)
On 2/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> I remove
I removed to clazz to commons.
Why are you asking, any problems ?
On 2/22/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> Stan,
> The PortletUtil class currently only works with the MyFaces
> implementation, right?
> Therefore I think we should move it to impl source root to make this
> clear f
Bruno Aranda schrieb:
> We used the convertedId javax.faces.DoubleTime, due to an error in the
> spec (or the javadoc) for JSF 1.1. In JSF 1.2 this has been fixed, but
> I suggest to use the wrong converterId in 1.1 to pass the TCK and to
> have the same behaviour than the RI...
>
Ups, sorry! I
We used the convertedId javax.faces.DoubleTime, due to an error in the
spec (or the javadoc) for JSF 1.1. In JSF 1.2 this has been fixed, but
I suggest to use the wrong converterId in 1.1 to pass the TCK and to
have the same behaviour than the RI...
Regards,
Bruno
On 2/22/06, [EMAIL PROTECTED] <
Laurie,
We use a Scriptlet API down in :
oracle.adfinternal.view.faces.renderkit.core.xhtml.jsLibs
... the basic gist of which is that a Renderer can say
"hey, I need function foo()", and the Scriptlet API
figures out whether that means importing a lib, or
writing out an in-place script, and
Stan,
The PortletUtil class currently only works with the MyFaces
implementation, right?
Therefore I think we should move it to impl source root to make this
clear for the end user.
Any objections to this?
Manfred
Have you looked at this?
http://wiki.apache.org/myfaces/External_Resources
On 2/22/06, Laurie Harper <[EMAIL PROTECTED]> wrote:
> The Tomahawk components 'inject' Javascript file references into the
> section of the response by using a filter to buffer and
> post-process the response. I'm assum
Werner Punz wrote:
Laurie, cannot help you there, but a minor sidequestion, did you use my
dojo hooks I provided in the sandbox?
If yes please give me feedback if you need something changed
or added, now is a perfect time for doing it, the whole dojo base will
be moved into Tomahawk after 1.1.2,
NullpointerException in MyFacesGenericPortlet after action-invocation
-
Key: MYFACES-1150
URL: http://issues.apache.org/jira/browse/MYFACES-1150
Project: MyFaces Core
Type: Bug
Environment: XP / JBo
[ http://issues.apache.org/jira/browse/MYFACES-1127?page=all ]
Mario Ivankovits reopened MYFACES-1127:
---
current solution didnt work if you reference the *listener through the var=
attribute (e.g. within an datatable)
> Non-null return types allo
Now that I have thought about Manfred's proposal its starting to make
more sense to me. Here is my revised proposal. It will allow us to
make progress on this and still defer the final decision for several
days.
1.) Create a "shared" subproject. Leave the trunk empty and copy the
existing commo
Nice catch Mario. Please comment out this code if you have not already. As
well as reopen the JIRA issue it is associated with.
Dennis Byrne
>-Original Message-
>From: Mario Ivankovits [mailto:[EMAIL PROTECTED]
>Sent: Wednesday, February 22, 2006 05:14 AM
>To: 'MyFaces Development'
>Su
This is a really big issue to wrap our collective heads around. Maybe
we should focus on the immediate problem first? The immediate
problem, as I see it, is that we are about to release the core and it
has shared code that will potentially conflict with the same shared
code in tomahawk.
It will
> Once our refactoring of commons classes into namespace
> org.apache.myfaces.commons.* is done we can easily change namespace
> for inlining by doing String search and replace on source level:
> replace "org.apache.myfaces.commons" by
> "org.apache.myfaces.impl-commons" (or alike)
> I already have
StateUtils has a static inializer that calls FacesContext.getCurrentInstance()
--
Key: MYFACES-1149
URL: http://issues.apache.org/jira/browse/MYFACES-1149
Project: MyFaces Core
Type: Bug
> The issue that John raises that interests me is the future inclusion
> of Tobago and ADF. There may be code that could be shared between
> these two projects and Tomahawk that has nothing to do with impl. So
> essentially we are talking about another core for components.
A perfect candidate fo
I agree with Manfred that we should not rename the implementation jars
(myfaces-impl.jar and myfaces-api.jar) for the reasons he has stated.
Even if you take Maven out of the picture you don't want to clash with
jar names the RI is using.
Naming is only a small part of what John is suggesting, ho
I just don't think its necessary regardless of whether it works. If
you want to leave them that's ok but I think its overkill and makes
the code slightly longer and more difficult to read.
I wouldn't be in a hurry to remove them - just whenever we spot one
and we're committing anyways.
Sean
On
Once our refactoring of commons classes into namespace
org.apache.myfaces.commons.* is done we can easily change namespace
for inlining by doing String search and replace on source level:
replace "org.apache.myfaces.commons" by
"org.apache.myfaces.impl-commons" (or alike)
I already have a working p
> To reduce the risk of version conflicts and to make the release cycle
> of core and tomahawk really independent, the shared classes should not
> be released as JAR, but should automatically be repackaged and
> "inlined" into impl, tomahawk, tobago, etc.
>
> Thoughts?
>
> Manfred
Interesting id
Maybe, but also the $Author$ was changed in one case and not in the other case.
Manfred
On 2/22/06, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> $Rev$ does the trick ;-)
>
> On 2/22/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > ok, fine.
> > It also seems to work sometimes and sometimes
$Rev$ does the trick ;-)
On 2/22/06, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> ok, fine.
> It also seems to work sometimes and sometimes not.
> I recently checked in two classes. One had the "last modified" and
> "revision" updated one not. Curious. Ok, let's get rid of these.
>
> Manfred
>
>
>
ok, fine.
It also seems to work sometimes and sometimes not.
I recently checked in two classes. One had the "last modified" and
"revision" updated one not. Curious. Ok, let's get rid of these.
Manfred
On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> We stopped using them a while ago. SVN
We stopped using them a while ago. SVN keeps track of who last
modified etc. In fact, SVN tells you who last modified what line (svn
blame). A while back I seem to recall us deciding that since SVN is
keeeping track of all of this there was no need to keep up the
practice.
Sean
On 2/22/06, Man
Sean,
is there an important reason for not having these svn "macros"?
Manfred
On 2/22/06, Apache Wiki <[EMAIL PROTECTED]> wrote:
> Dear Wiki user,
>
> You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for
> change notification.
>
> The following page has been changed by scho
A Tabbed Pane doesn't update the model.
---
Key: TOMAHAWK-153
URL: http://issues.apache.org/jira/browse/TOMAHAWK-153
Project: MyFaces Tomahawk
Type: Bug
Components: Tabbed Pane
Versions: 1.1.1
Environment: Windows XP,
Hi all,
Some more investigations and thinking led me to the following conclusion:
Key to all that confusion (me beeing the most concerned ;-) and to our
divergent points of view regarding commons release policy,
auto-repackaging (aka "inlining"), etc. is the mixture in the type of
classes we curren
[ http://issues.apache.org/jira/browse/TOMAHAWK-136?page=all ]
sean schofield closed TOMAHAWK-136:
---
Fix Version: 1.1.2-SNAPSHOT
Resolution: Fixed
> Schedule component: Add rowheight property to the detailed view (Day View)
> similar to Mont
I will look into it now. In the future you can use the new "Provide
Patch" method that I added to our JIRA workflow. This will indicate
that a patch has been provided and help us to spot issues that have
patches and are still open.
Sean
On 2/22/06, Jurgen Lust <[EMAIL PROTECTED]> wrote:
> Hi,
>
There is a new version of JIRA that makes it easier to do bulk
closing. Ideally we only resolve and then close when we release.
Infra does not want to upgrade JIRA yet because of a possible memory
leak issue.
They have suggested this type of bulk close can be done with a jelly
script[1]. They a
[ http://issues.apache.org/jira/browse/TOMAHAWK-66?page=all ]
sean schofield updated TOMAHAWK-66:
---
> add colspan (and header/footer colspan) attributes to tomahawk extended
> column tag
> ---
On the branch only. We'll merge it down to the trunk later.
On 2/22/06, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
> Sean Schofield schrieb:
> >
> > @Bernd: Can you still reverse the change you made last month where we
> > took the deps out of assembly?
>
> On the trunk and 1_1_2 branch or on the t
Hi Volker!
> Havend looked into sources yet, but imo we sould not remove this test,
> but log at warn level and continue processing.
>
Please not at warn level. "debug" should be sufficient.
What should it be good for to log a warning that we cant check the
return type of the listener.
This war
Hi Mario,
On 11:14 Mario Ivankovits wrote:
> What to do now?
> I think the first thing to do is to remove these checks, later we can
> find a better approach.
>
Havend looked into sources yet, but imo we sould not remove this test,
but log at warn level and continue processing.
Aliasbean would
Hi Sean,
according to
http://wiki.apache.org/myfaces/MyFaces_Developer_Notes
> Issues should be marked as closed at the same time that an issue is
marked as resolved.
I have seen a 'Resolve and Close' button in other jira applications,
could we add such a button?
Regards,
Volker
--
Don't a
Hi all,
I would like to access an alias bean from a jsp code how can i do that ?
Any Ideas ?
Thanks a lot
Sébastien Boutte
My first page is :
My second Page:
<%
Object value = retrieveMethod("monBean2");
%>
jsf code
I try several methods but all return null value:
1.
FacesContext
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Thomas,
can you sent these questions to the mailing list in the future?
We need the error message to track down the problem! Normally you should have
no troubles building
tobago from source. Just follow the instructions here:
http://tobago.at
Hi!
In UIComponentTagUtils the "Void"-check for the return-type of the
listener cant be evaluated e.g. within an dataTable - or any other
component using a var= attribute.
This is due to the fact that the var= attribute hasnt processed so far
and thus the getType() cant find the method (base is nu
Laurie Harper schrieb:
> The Tomahawk components 'inject' Javascript file references into the
> section of the response by using a filter to buffer and
> post-process the response. I'm assuming ADF Faces has some mechanism for
> injecting Javascript too, but I can't seem to track it down...
>
> I
Hi, I prefer (sandbox) or (sbx), and avoid the *
Bruno
On 2/21/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I moved the sandbox stuff but I did not create the components yet.
> I'll wait to see what people think about * or (sbx) or whatever.
>
> Also, I deleted the 'other' component so most is
Hi,
Has anyone had the chance to apply the patch for tomahawk issue 136?
I'm working on some new stuff, but I need that patch applied before I
can continue...
Kind regards,
Jurgen
+1 Sounds ok to me. If not it is hard to find those issues with
patches, and you find the patch when it is not useful anymore because
it was provided some time ago...
Regards,
Bruno
On 2/22/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
> I made another improvement to our JIRA setup. I added a "
You're filling up your plate quite well!
;)
regards,
Martin
On 2/22/06, Jacob Hookom <[EMAIL PROTECTED]> wrote:
> It was developed last spring, it's been used as the foundation for EL
> within the JSF RI and Glassfish's JSP impl, as far as I know, there
> haven't been any bug fixes or issues a
On 2/21/06, John Fallows <[EMAIL PROTECTED]> wrote:
> Folks,
>
> There seems to be increasing discussion lately regarding MyFaces Commons and
> how it relates to both MyFaces Core and MyFaces Tomahawk.
>
> Adding Tobago and ADF Faces to the discussion makes it even more critical
> that we come up w
92 matches
Mail list logo
