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 with 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 and
+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
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
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 issues
Laurie Harper schrieb:
The Tomahawk components 'inject' Javascript file references into the
head 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...
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
-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:
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 :
t:aliasBean alias=#{monbean2} value=#{monbean1}
jsp:include page=page2.jsp
/t:aliasBean
My second Page:
%
Object value =
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
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 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 warning
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 trunk only?
[ 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
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
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,
Has
[ 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
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
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,
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 schof:
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,
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 keeps
$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
On 2/22/06,
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 idea. Do
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
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
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,
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 for
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
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
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
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'
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
[ 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
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 /
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,
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
head section of the response by using a filter to buffer and
post-process the response. I'm
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
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
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]
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 just
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 for the
[
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
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
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
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
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
[
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
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
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
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
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
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: The MyFaces
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
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 edit
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
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
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
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]
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
Werner Punz wrote:
Laurie Harper schrieb:
The Tomahawk components 'inject' Javascript file references into the
head 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
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 be
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.
s:effect has a bunch of attributes with rtexprvaluetrue/rtexprvalue , 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
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
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
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:
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
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
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
No...
I will fix that asap
Dennis Byrne schrieb:
s:effect has a bunch of attributes with rtexprvaluetrue/rtexprvalue , is
this intentional?
Dennis Byrne
-Original Message-
From: Werner Punz [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 22, 2006 04:21 PM
To:
[
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
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 addons
[
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
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.
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
76 matches
Mail list logo
