Hi!
I don't think a separation between api and impl jars is useful.
I second that. For the same reasons. It makes things unnecessary
complicated
To ensure api stability community review should be enough - and then
there is a maven plugin for that, no?
BTW: I thought we agreed on a
I don't think a separation between api and impl jars is useful.
Myfaces core has broken code I've been working on many times. And the issue
there is not a change in the api (the JSF api is clearly static). Instead the
problem has been changes in behaviour.
So a stable API jar only solves about
Six additional lines for the user (as long as he/she uses maven ;-) is
not that much more additional inconvenience I think:
dependency
groupIdmyfaces-jsfcommons/groupId
artifactIdmyfaces-jsfcommons-impl/artifactId
version1.0.0/version
On Nov 29, 2007 9:34 AM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I don't think a separation between api and impl jars is useful.
I second that. For the same reasons. It makes things unnecessary
complicated
To ensure api stability community review should be enough - and then
[
https://issues.apache.org/jira/browse/TRINIDAD-843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf resolved TRINIDAD-843.
-
Resolution: Fixed
Fix Version/s: 1.2.5-plugins
Jdev plugin -
[
https://issues.apache.org/jira/browse/TRINIDAD-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthias Weßendorf updated TRINIDAD-177:
Resolution: Fixed
Fix Version/s: (was:
[
https://issues.apache.org/jira/browse/TRINIDAD-177?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546616
]
Aino Andriessen commented on TRINIDAD-177:
--
Great.
Note, this same issue also applies to the 11g project
Hi!
I am trying to create a master-detail screen scenario and am following the
best-practices guide in the wiki (the simple CRUD cycle -
http://wiki.apache.org/myfaces/A_simple_Crud_Cycle) and it does not actually
work. Am I doing something wrong?
Unhappily the author of this page did not say
Hi!
well, when we put in the converters/validators, we will also have faces-cfg
for them...
Yep, if we have separate projects we can have the faces-config.xml again.
Regarding the sandbox: I'd like to suggest to use the tomahawk sandbox
for myfaces land at all. Lets promote the
Oh no! Seems like we are going round in circles... :-(
WHAT is the FOCUS of a jsfcommons project?!
Do we really want component like stuff like converters and validators there?
Didn't we discuss this already?
I thought we agreed on not starting yet another jsf component lib.
What is wrong with
hrm..
shouldn't it be on tree ?
On Nov 28, 2007 11:19 PM, Abhinav Korlakunta
[EMAIL PROTECTED] wrote:
Hi,
I am trying to use 'rowSelection' attribute on 'tree' component but I am not
able to find it in the tag documentation attribute list.
But here,
I revert my -1; since I replaced the broken plugins release.
So, here is my +1
-M
On Nov 29, 2007 8:41 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
coool, will check that all.
On Nov 29, 2007 1:11 AM, Gary Kind [EMAIL PROTECTED] wrote:
Done.
Scott O'Bryan wrote:
Actually
Hi Manfred!
Oh no! Seems like we are going round in circles... :-(
Seems like.
A mail (31.10.2007 21:59) from you
And don't forget about all those (renderkit-independent!) converters
and validators. People might argue for putting them into a jsfcommons
components artifact. What about the
I'd love to see things like:
http://svn.apache.org/viewvc/myfaces/tobago/trunk/core/src/main/java/org/apache/myfaces/tobago/servlet/NonFacesRequestServlet.java?view=markup
in a util.
(oh boy, it all starts again)
-M
On Nov 29, 2007 10:25 AM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi
:-)
currently (which is wrong)
/tom
/tom/sandbox
it should:
/tom
/tom-sandbox
On Nov 29, 2007 10:04 AM, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
well, when we put in the converters/validators, we will also have faces-cfg
for them...
Yep, if we have separate projects we can have
On Nov 29, 2007 10:07 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
Oh no! Seems like we are going round in circles... :-(
WHAT is the FOCUS of a jsfcommons project?!
Do we really want component like stuff like converters and validators there?
hu? yes!
Didn't we discuss this already?
I
Hi!
If we need jar supporting component-developer we should stop the
repackaging of shared, create a shared.jar and add the dependency
instead to impl and tomahwak.
Oh ... how much I'd love this to happen
Ciao,
Mario
Do we really want component like stuff like converters and validators there?
Didn't we discuss this already?
Yes we had discuss this, but it seems we did not reach agreement.
I think we need a own project for converters/validators/other stuff
for application-development
which should not
Hi,
2007/11/29, Manfred Geiler [EMAIL PROTECTED]:
Oh no! Seems like we are going round in circles... :-(
WHAT is the FOCUS of a jsfcommons project?!
Do we really want component like stuff like converters and validators there?
Didn't we discuss this already?
Yes we had discuss this, but it
JDev plugin - compiler configuration 11g
-
Key: TRINIDAD-846
URL: https://issues.apache.org/jira/browse/TRINIDAD-846
Project: MyFaces Trinidad
Issue Type: Bug
Components: Plugins
Hmpf
Last time the discussion ended with some open issues.
I think it's all about naming. That's the main reason for different
views and opinions I think.
To gain a common view on things I try to subsume without giving names first.
The stuff we have (or plan to have) and we need places for are:
Hi!
that would easy the debugging as well.
why? If you have both sources for api and impl jar in your IDE there
is no difference.
It IS. You have to know at which class to set a breakpoint. Even if you
see a shared class, you have to set the breakpoint to the refactored
[
https://issues.apache.org/jira/browse/TOMAHAWK-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546714
]
Alexander Jesse commented on TOMAHAWK-63:
-
A test using
- Tomahawk 1.1.7-snapshot (testing Martin's mods
The stuff we have (or plan to have) and we need places for are:
1. renderkit independent stuff - converters, validators, ... (BTW,
are they really renderkit independent? What about client-side
validation?!)
2. convenient utils, helpers and base classes for component developers
3.
[
https://issues.apache.org/jira/browse/TOMAHAWK-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12546723
]
Alexander Jesse commented on TOMAHAWK-1072:
---
My test using
- Tomcat 6
- SUN-RI 1.2_06
- Facelets 1.1.11
yes, yes, of course - sorry. I should read more carefully. I thought
Matthias meant that it's easier to debug if you do not have splittet
jars - API and Impl. One of the other 7 discussions we are having
concurrently within this thread, you know. ;-)
Debugging shared IS horror today, sure!
The stuff we have (or plan to have) and we need places for are:
1. renderkit independent stuff - converters, validators, ... (BTW,
are they really renderkit independent? What about client-side
validation?!)
let me write a wiki page for that + discussion in a separate thread.
-M
2.
On 11/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
that would easy the debugging as well.
why? If you have both sources for api and impl jar in your IDE there
is no difference.
It IS. You have to know at which class to set a breakpoint. Even if you
see a shared class, you
Hi,
just my few ideas about this ;)
What about reversing the flow by answering the 'simple question':
What code is specific to render kit?
By answering this question we can really begin discussion about the
way of putting remaining classes to so called 'commons'.
-
My current view
sure, no dependency to -impl.
Wouldn't make sense, if there were.
Convertors and validators are quite different matter - they should get
into 'commons' BUT if and only if they use only crucial attributes from
(server-side) converters and (server-side) validators, are really
reusable
HI you all
This is a repost, as I have not got a solution to my question by tomahawk
developers (this is regarding the Extension Filter class
org.apache.myfaces.webapp.filter.ExtensionsFilter which I consider there is a
bug because the resulting page gets HTML encoded which should not be, that
Hi,
Matthias Wessendorf napsal(a):
sure, no dependency to -impl.
Wouldn't make sense, if there were.
Convertors and validators are quite different matter - they should get
into 'commons' BUT if and only if they use only crucial attributes from
(server-side) converters and
Hi,
the tags for converters/validators e.g. must be in here, or the
components are not useable.
Regards,
Volker
2007/11/29, Sochor Zdeněk [EMAIL PROTECTED]:
Hi,
Matthias Wessendorf napsal(a):
sure, no dependency to -impl.
Wouldn't make sense, if there were.
Convertors and
I think it should contain tags for:
-jsp (that guy is default in JSF spec)
-facelets (that guy is more and more used)
There are NO tags in JSF API (they are ALL in impl), so they don't have
a foundation to be built upon.
...
These files (tags, descriptors) should go to project where
Exactly,
that would be a poor man's API :-)
I'd not buy such a lib
-M
On Nov 29, 2007 4:22 PM, Volker Weber [EMAIL PROTECTED] wrote:
Hi,
the tags for converters/validators e.g. must be in here, or the
components are not useable.
Regards,
Volker
2007/11/29, Sochor Zdeněk [EMAIL
+1 for me as well, thanks for the patch :)
On Nov 29, 2007 2:20 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I revert my -1; since I replaced the broken plugins release.
So, here is my +1
-M
On Nov 29, 2007 8:41 AM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
coool, will check that
Hi,
the tags for converters/validators e.g. must be in here, or the
components are not useable.
I should have made myself little clearer - i was speaking of components,
not converters/validators.
I was ONLY speaking here about converters/validators.
API (containing the
Hey everyone,
I'm going to try to put together a proposal for some items it add to the
jsf commons fairly soon for your purusal. First off, however, I'd like
some technical information on this project as it may effect how the
project is set up.
1. Which version of JSF will be the minimum
On Nov 29, 2007 6:06 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Nov 29, 2007 5:57 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey everyone,
I'm going to try to put together a proposal for some items it add to the
jsf commons fairly soon for your purusal. First off, however, I'd
If 1.1 is a must then I don't see any way around having 2 trunks. The
API's between the two are not the same and when dealing with things like
decorators (which JSF makes extensive use of), you need to implement
every method on a class and ONLY those methods.
I know that for Trinidad,
Thanks. I did figure out some of these approaches, but was wondering if I
was missing something as none
of them match the example! Of course, the proposed solutions that involve
sharing the conversation between master and detail or invalidating the
master from the detail mean that calling
Read-only controls don't get focus automatically
Key: TOBAGO-560
URL: https://issues.apache.org/jira/browse/TOBAGO-560
Project: MyFaces Tobago
Issue Type: Improvement
Components:
[
https://issues.apache.org/jira/browse/TOBAGO-560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arvid Hülsebus resolved TOBAGO-560.
---
Resolution: Fixed
Avoid auto-focus for read-only input controls
to make it clear.
I am not saying, that JSF 1.1 API is the ONLY ONE.
Because this is a new project, a JSF 1.2 ONLY *would* make sense...
but... JSF 1.1 is still in use...
Perhaps a second trunk for 1.1-based JSF is a good thing (tm)
-Matthias
On Nov 29, 2007 6:16 PM, Scott O'Bryan [EMAIL
Hi Carlos,
I've done some work on the ExtensionsFilter in the past.
You may well be right that this class is the cause of your problems. It does
create a fake ResponseWriter object in order to buffer all the data generated
for the page. It then performs some post-processing of the generated
I certainly would be interested in contributing to a tomahawk-1.2 line, but not
particularly interested in a tomahawk-1.1 line.
It is necessary to test stuff that is added/modified, but compiling then
testing against both versions of JSF will be painful. And writing components
that work with
Scott O'Bryan escreveu:
If 1.1 is a must then I don't see any way around having 2 trunks.
WDYT about use different pakages for different versions (incompatible
stuff only) like Spring did for Hibernate version 2 and 3?
org.springframework.orm.hibernate = for Hibernate 2.x
and
Hi!
I'm developing portlets and the portal allows me to position the
screen on a particular portlet using anchors... Like
#p_my_particular_portlet
I have a portlet with links to other pages and I want to use the
anchors to give focus to my_particular_portlet
When i do this in an
Ensure that correct default button is activate after Ajax request
-
Key: TOBAGO-561
URL: https://issues.apache.org/jira/browse/TOBAGO-561
Project: MyFaces Tobago
Issue Type:
Ok, I'm assuming at this point that we are going to have a 1.1 AND a 1.2
branch for the commons. If this is not the case some of the following
may be impossible. But I would like people's input on this to see if
it's something they would be interested in.
1.
We CAN... But the compile time requirements will be different. And the
real concern I have is that this commons project is a slave to another
project which means we are at the mercy of the JSF api's. If they
change, implementations need to change and it may not always be possible
to have
Hazza. It would also allow, possibly, a Tobago 1.2 line to move forward
a bit easier..
Scott
Simon Kitching wrote:
I certainly would be interested in contributing to a tomahawk-1.2 line, but not
particularly interested in a tomahawk-1.1 line.
It is necessary to test stuff that is
Gracias, Simon
I am using tomahawk version 1.1.6 and I think this match must be present in
this version, I will check, by the way, I am new to this process and I actually
happen not to know what to do with the add_resource_encoding.diff file and how
I am to compile the source.
Debugging is an
Hi Arvid,
setDefaultAction: function(defaultActionId) {
var field = Tobago.element(Tobago.page.id + Tobago.SUB_COMPONENT_SEP
+ form-action);
if (field) {
field.value = defaultActionId;
}
}
could be simplified to
setDefaultAction: function(defaultActionId) {
Tobago.action.value =
Alex,
Yeah, that's not going to work. In the servlet case, what you are
proposing does just fine, but in the portlet case, encoded url's
actually turn into something entirely different and the bookmark (#)
notation is not something that is supported by JSR168. I would look at
having your
Not only that attribute, it is missing all other autoSubmit, partialSubmit ...
But it does have selectionListener, which will not work until we have those
attributes. Is this functionality removed intentionally? Does anybody used it
before?
Thank you,
-Abhinav.
Hi guys,
I sorry I test all the cases written on this page, but still dont work for
me. Ids are still displayed several times.
MyFaces version :
!-- myfaces --
dependency
groupIdorg.apache.myfaces.core/groupId
artifactIdmyfaces-api/artifactId
version1.2.0/version
It's fixed for 1.1.6-SNAPSHOT and 1.2.1-SNAPSHOT.
It's NOT fixed for 1.2.0 that was released months ago, of course.
;-)
--Manfred
On Nov 29, 2007 9:11 PM, xtof83 [EMAIL PROTECTED] wrote:
Hi guys,
I sorry I test all the cases written on this page, but still dont work for
me. Ids are still
You're right, I get the code, and I compile it... now it work perfectly.
Thx
Manfred Geiler wrote:
It's fixed for 1.1.6-SNAPSHOT and 1.2.1-SNAPSHOT.
It's NOT fixed for 1.2.0 that was released months ago, of course.
;-)
--Manfred
On Nov 29, 2007 9:11 PM, xtof83 [EMAIL PROTECTED]
[
https://issues.apache.org/jira/browse/TOBAGO-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Volker Weber resolved TOBAGO-557.
-
Resolution: Fixed
Fix Version/s: 1.0.13
Selection problem with tc:treeListbox
hrm...
not sure, but isn't the schema not part of the jar?
On Nov 29, 2007 8:41 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey everyone,
The PortletBridge project has a schema that we need to make available
for some of the faces-config extensions outlined in the most recent
spec. I was
Not sure. I was looking for the JSF one and I know it's online but I
couldn't find it in the JAR anywhere. Let me look again.
Scott
Matthias Wessendorf wrote:
hrm...
not sure, but isn't the schema not part of the jar?
On Nov 29, 2007 8:41 PM, Scott O'Bryan [EMAIL PROTECTED] wrote:
Hey
I guess you are saying that JSF will change the # into something...
If i use a link out of JSF the anchor works fine... I'll see about
using verbatim or something around those lines then...
thanks!
On Nov 29, 2007, at 1:29 PM, Scott O'Bryan wrote:
Alex,
Yeah, that's not going to work.
More to the point, the PORTAL will change the #, not JSF. If you're
interested in a technical explanation let me know. :)
Scott
Alexander Wallace wrote:
I guess you are saying that JSF will change the # into something... If
i use a link out of JSF the anchor works fine... I'll see about
tableSuggestAjax not render with trinidad
-
Key: TOMAHAWK-1157
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1157
Project: MyFaces Tomahawk
Issue Type: Bug
Affects Versions: 1.1.7-SNAPSHOT
There must be a way for the portlet bridge to bundle the schema it needs
inside its jar, and register it with JSF so that the local copy is
used and not one downloaded from the network.
A library that requires over-the-internet access to its schema in order
to run would be horribly wrong.
On
Andrew,
today the plugins 1.2.5 will be out, I'll include them into the 1.2.4 CORE
and I suggest to use the TAG for 1.2.4 (after the release is out), to create
the 1.2-x trunk
-Matthias
On Nov 27, 2007 6:59 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
ok, my 1.2.4 will arrive on the
Hi!
Mario Ivankovits [EMAIL PROTECTED] schrieb:
I don't see any reason why we shoulnd't being able to provide a stable
api even for shared.
I have to strongly disagree here.
I know what all this means, but, this statement, and what Manfred wrote
means, that MyFaces is not
can't get changed value with t:inputCalendar readonly property.
-
Key: TOMAHAWK-1158
URL: https://issues.apache.org/jira/browse/TOMAHAWK-1158
Project: MyFaces Tomahawk
Issue
69 matches
Mail list logo
