Probably in the facelets repository, if it's not part of the JSF 2.0
implementation.
:pserver:user@cvs.dev.java.net:/cvs
Branches include:
JSF_2_0_0_AJAX
JSF_2_0_0_AJAX_20080713_BRANCH
JSF_2_0_0_from_HEAD_20080606_BRANCH
On Thu, Aug 6, 2009 at 9:26 AM, Curtiss
For awhile, 2.0 changes for facelets were being committed to the
JSF_2_0_0_from_HEAD_20080606_BRANCH facelets branch.
I'm not sure if that's still the case or if the branch was forked elsewhere.
On Wed, Aug 5, 2009 at 9:11 AM, Matthias Wessendorfmat...@apache.org wrote:
On Wed, Aug 5, 2009 at
I was looking for a 1.1.9 sandbox snapshot prebuilt.
Our link to the maven repository points to a Nov 2008 version.
http://wiki.apache.org/myfaces/FAQ#download-other-stuff
I looked around for a bit trying to find something more current, but I
wasn't able to do so.
Do we no longer produce
+1
On Tue, Jun 9, 2009 at 2:56 PM, Curtiss Howardcurtiss.how...@gmail.com wrote:
On Tue, Jun 9, 2009 at 2:32 PM, Gerhard
Petracekgerhard.petra...@gmail.com wrote:
hi,
short description:
this first vote is about the switch from commons-logging (cl) to
java.util.logging (jul).
it's a
I'd strongly prefer to see JUL instead of something else (including
JCL) now that it's part of the standard. In Ganesh-speak, +0.9 JUL,
-0.9 slf4j
On Sat, Jun 6, 2009 at 6:37 AM, Mario Ivankovits ma...@ops.co.at wrote:
Hi!
The only downside I see is that we might break compatibility for java
Is this really a bug? I'd say it's a feature. Some design experts
insist that buttons merely be greyed out rather than removed when
inactive. That would not be possible if the next/previous facets are
not rendered at all times. I'd say that the children of that facet
should be able to
Yes, I looked at this library for GWT work a couple weeks ago. It's
compatible in theory, but not in practice.
On Wed, May 27, 2009 at 6:23 AM, Ganesh gan...@j4fry.org wrote:
AFAIK ExtJS may not be altered and resold commercially - they have a 2nd
commercial license. The whole thing is
I don't know much about git, but I know that other committers on
Apache Cayenne use git to commit to the Cayenne svn, so it's certainly
possible to do what Andrew suggests. From my limited git
understanding, that's the typical practice of using git -- as a
front-end to svn or cvs.
On Fri, May
Unfortunately, I don't have any knowledge about the ajax work you are
all doing. However, I am -1 on anything that tries to intentionally
break spec compatibility, such as reusing the f: namespace. Even if
it's not explicitly spelled out, we know that it's against the spirit
of the spec. I find
A simple pluggable API sounds like a reasonable approach to me. For
some situations, a pure reflection scanner might work better. For
others, it won't scale. You might need to temporarily switch to a
different scanner to determine if it's the cause of some particular
bug. Or perhaps the
Make sure you're doing all work in the JSF component, and none in a
JSP tag handler. The tag handler should simply assign properties set
on the tag to the component.
That will take care of the problem in general. There are specific
cases where no component exists that have to be handled by
+1
On Tue, Jan 20, 2009 at 4:04 PM, Scott O'Bryan darkar...@gmail.com wrote:
Hey community,
Oracle is trying to open up a new JSR for the Portlet 2.0 Bridge.
Originally this was part of the JSR-301 but there was a slight
misunderstanding of the intentions of the specs regarding release
Just a comment that Sameo isn't useful if someone doesn't see this
in the context of the previous commit.
On Mon, Nov 24, 2008 at 7:02 PM, [EMAIL PROTECTED] wrote:
Author: sobryan
Date: Mon Nov 24 16:02:10 2008
New Revision: 720358
URL: http://svn.apache.org/viewvc?rev=720358view=rev
Log:
+1
On 11/14/08, Grant Smith [EMAIL PROTECTED] wrote:
+1
On Fri, Nov 14, 2008 at 7:41 AM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
+1
On Fri, Nov 14, 2008 at 4:36 PM, Andrew Robinson
[EMAIL PROTECTED] wrote:
+1
On Thu, Nov 13, 2008 at 4:21 PM, Gerhard Petracek
I'd say that there's no reason to deprecate a class clearly packaged
as trinidadinternal.
On 11/14/08, Jeanne Waldman [EMAIL PROTECTED] wrote:
Actually, I decided to be on the safe side to deprecate it, even if it is
just for one release.
Jeanne
Jeanne Waldman wrote, On 11/14/2008 9:03 AM
What about Simon's suggestion that we promote it to commons instead of
Tomahawk? Any reason not to go down that path?
On Wed, Nov 12, 2008 at 8:21 PM, Hazem Saleh [EMAIL PROTECTED] wrote:
Refactoring is done.
Tomorrow will promote the component to Tomahawk.
On Wed, Nov 12, 2008 at 11:00 PM,
Robinson [EMAIL PROTECTED]
Since it doesn't render anything, perhaps it should?
On Thu, Nov 13, 2008 at 12:27 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
What about Simon's suggestion that we promote it to commons instead of
Tomahawk? Any reason not to go down that path?
On Wed, Nov
: website
Reporter: Mike Kienenberger
http://myfaces.apache.org/tomahawk/source-repository.html incorrectly gives the
online svn repository link as follows:
http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/tomahawk-site
I'm guessing it should be:
http://svn.apache.org/viewcvs.cgi
[
https://issues.apache.org/jira/browse/TOMAHAWK-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12644724#action_12644724
]
Mike Kienenberger commented on TOMAHAWK-1367:
-
The reason we won't fix
http://myfaces.apache.org/tomahawk/source-repository.html incorrectly
gives the online svn repository link as follows:
http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk/tomahawk-site
I'm guessing it should be:
http://svn.apache.org/viewcvs.cgi/myfaces/tomahawk/trunk
[
https://issues.apache.org/jira/browse/TOMAHAWK-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Kienenberger reopened TOMAHAWK-1367:
-
Wrong resolution status.
ClassCastException in HtmlDataTable newspaperColumns
[
https://issues.apache.org/jira/browse/TOMAHAWK-1367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12644363#action_12644363
]
Mike Kienenberger commented on TOMAHAWK-1367:
-
One final note: If it won't
evaluated it.
On Tue, Feb 20, 2007 at 10:52 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Does this help?
#Generated by Maven
#Thu Apr 13 14:18:08 EDT 2006
version=2.0.0
groupId=org.apache.myfaces.shared
artifactId=myfaces-shared-impl
So perhaps the change that needs to be made
[
https://issues.apache.org/jira/browse/TOMAHAWK-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Kienenberger updated TOMAHAWK-1307:
Status: Patch Available (was: Open)
#00 is displayed in inputHtml
On Fri, Oct 24, 2008 at 5:27 AM, Simon Kitching [EMAIL PROTECTED] wrote:
The latest maven-clirr-report plugin unfortunately crashes on orchestra, but
I have created a report using clirr trunk; please see here:
+1 only for components that don't render anything, like t:saveState
Rob Williams describes some of the pain I've experienced in the past
with JSF. You have complicated Domain dynamic hierarchies. You
don't want to be trying to create a dynamic hierarchy of Data Transfer
Objects that you then have to maintain, populate and transfer. So
what do you do?
Ryan
I think what Manfred is suggesting is that we implement a reCAPTCHA
component specifically rather than captcha in general. For those
people who want to secure their applications and promote digital book
scan correcting at the same time :-)
On 8/14/08, Hazem Saleh [EMAIL PROTECTED] wrote:
Hi
Sure, that's what the section is for.
On 7/14/08, Jihoon Kim [EMAIL PROTECTED] wrote:
So that is the update and I was hoping if I could modify the
Frameworks related to JSF section within the MyFaces Wikipage to
include a link to FlexFaces project in order to increase the exposure
of the
, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn that guy on. So, that fixes it.
Sandbox still
This will still crash if rc.getAgent() ever returns null. I don't
know if that's a possibility.
On 7/8/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: matzew
Date: Tue Jul 8 09:41:52 2008
New Revision: 674871
URL: http://svn.apache.org/viewvc?rev=674871view=rev
Log:
What Simon proposed makes a lot of sense to me.
On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Andrew Robinson schrieb:
You must have had a real use case that pushed you to write this
component.
Can you please describe it?
The same as all usages of c:choose /.
I agree with Simon in that where the image usage is not under our
control (like t:graphicImage), we should not output an alt tag unless
the end-user specifies an alt tag.
On Mon, Jun 30, 2008 at 4:50 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
On Mon, Jun 30, 2008 at 12:15 AM, Hazem Saleh
If I understand correctly, the current state of the component is such
that it works with any UIData component. I'm +1 for keeping that
status. It'd be great if we could do something similar with many of
the other t:dataTable functionality.
On 6/27/08, simon [EMAIL PROTECTED] wrote:
I'm +1 to
On 6/26/08, Volker Weber [EMAIL PROTECTED] wrote:
Does it really matter if there's a commons 1.1? Tomahawk 1.1 is fast
approaching the end of its lifecycle.
Yes, it does. At least to me.
Commons1.1 is not a tomahawk1.1 extension, it should contain things
for jsf1.1 application
[
https://issues.apache.org/jira/browse/TOMAHAWK-1014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12608053#action_12608053
]
Mike Kienenberger commented on TOMAHAWK-1014:
-
Leave it open. It's a bug
On 6/25/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
s:validateCompareTo
And all that code about independently converting a component's submitted
value makes me a little nervous. It looks ok, but has anyone properly
reviewed it?
The code was pretty much copied verbatim from the Myfaces
On 6/25/08, simon [EMAIL PROTECTED] wrote:
On Wed, 2008-06-25 at 10:59 -0400, Mike Kienenberger wrote:
On 6/25/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
s:validateCompareTo
And all that code about independently converting a component's submitted
value makes me
Let's not forget that working on open source software is quite
different than working on proprietary software. For open source, you
work on what you need and you share what you've done with others.
Some people need JSF 1.1 and will be working there. Some people need
JSF 1.2 and will be working
It should be deprecated because it adds nothing over validateCompareTo
and does not do the job of locating/computing/comparing two equal
input component values as well as validateCompareTo does.
Or to look at it another way, defining a validateEquals jsp or facelet
tag handler that points to the
/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Use the sandbox convertNumber with a BigDecimal type.
Ok,
I don't use this now.
Since Java5 there is a parseBigDecimal() on DecimalFormat.
In Trinidad I just turn
[
https://issues.apache.org/jira/browse/TOMAHAWK-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605476#action_12605476
]
Mike Kienenberger commented on TOMAHAWK-610:
Other pitfalls to avoid when
Number is null.
5. Otherwise, the value passed validation.
--
On 6/16/08, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Mon, Jun 16, 2008 at 6:21 PM, Matthias Wessendorf [EMAIL PROTECTED]
wrote:
On Mon, Jun 16, 2008 at 6:19 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
Yes
Use the sandbox convertNumber with a BigDecimal type.
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser (DecimalFormat) as described in
http://issues.apache.org/jira/browse/TOMAHAWK-610
if it hasn't already been taken care of.
On 6/13/08,
PROTECTED] wrote:
thanks!
will have a look
On Fri, Jun 13, 2008 at 6:04 AM, Mike Kienenberger [EMAIL PROTECTED] wrote:
Use the sandbox convertNumber with a BigDecimal type.
You may also want to take a few minutes and add the workaround for the
bug in the java currency parser
http://myfaces.apache.org/trinidad/download.html
If it's not in a pre-build download, you can check it out from svn by
following the instructions on the same link above.
On 6/13/08, Ivan Li [EMAIL PROTECTED] wrote:
I download the source code from apache, but the the core component's source
+1 to promoting subform.
+1 to everything Volker said.
On 6/11/08, Volker Weber [EMAIL PROTECTED] wrote:
Hi Hazem,
i think you are a bit to fast. You started the vote at 9. Juni 2008 17:54
start committing the changes 44:20 hours:minutes (if i count correct)
later at 11. Juni 2008 14:14.
I'd recommend not migrating t:validateEqual across to myfaces-commons.
t:validateEquals is a special case of t:validateCompareTo, and, if I
recall correctly, the code in validateEquals is not as flexible as the
code in validateCompareTo. There's no point in maintaining the
inferior limited
[
https://issues.apache.org/jira/browse/TRINIDAD-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602661#action_12602661
]
Mike Kienenberger commented on TRINIDAD-634:
-int firstDOW
[
https://issues.apache.org/jira/browse/TRINIDAD-634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12602664#action_12602664
]
Mike Kienenberger commented on TRINIDAD-634:
+ private static final int
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
* @JSFJspProperty name = message inheritedTag=true returnType =
java.lang.String longDesc = alternate validation error message format
string
*/
public class CSVValidator extends ValidatorBase
Inheritance of properties for converters and
are subclassing a converter, there's
obviously some reason why you did it rather than writing one from
scratch.
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 3:21 PM, Mike Kienenberger [EMAIL PROTECTED]
wrote:
On 6/4/08, Leonardo Uribe [EMAIL PROTECTED] wrote
Another alternative to option 1 is to #parse($fileName) or #include($fileName).
You can specify filename externally. This is probably the best
solution so long as the contents of the file included can be included
as-is.
On 4/9/08, Leonardo Uribe [EMAIL PROTECTED] wrote:
Hi
I have another
I have not seen the specifics of this project, but if you're using
velocity, you should be able to have the code which initializes
velocity automatically populate something like $utils instead of doing
it in the velocity template language.
I also think you're better off NOT putting
On Thu, Apr 3, 2008 at 7:44 PM, Leonardo Uribe [EMAIL PROTECTED] wrote:
The drawback
is that creates a log file on the project folder (I'm not found how to
output the log on the screen yet!).
Have you looked at this page?
I've been following this thread on and off, so my apologies if you
already covered it,
but how different will syntax checking be with the javadoc annotations
vs xml? Xml editors automatically validate with schemas or dtds. Is
something similar available for javadoc annotations in the standard
,
Simon
On Fri, 2008-03-21 at 14:40 -0400, Mike Kienenberger wrote:
I've been following this thread on and off, so my apologies if you
already covered it,
but how different will syntax checking be with the javadoc annotations
vs xml? Xml editors automatically validate with schemas
[
https://issues.apache.org/jira/browse/MYFACES-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12577054#action_12577054
]
Mike Kienenberger commented on MYFACES-1834:
Wouldn't it make more sense
http://wiki.apache.org/myfaces/Code_Generation
2) Generating base classes instead of templates from xml-config-files
For what it's worth, what you're describing here is the Generation Gap
pattern. I've got a lot of experience using it with Cayenne over the
years (and WebObjects years before
If something was publicly released as 1.2.1 already, then -- even if
it was pulled -- please do not release 1.2.1 again.
Skipping a version number might cause some questions on the list.
However, reusing a version number will result in the end user not
knowing if they have the good version or the
On Jan 21, 2008 4:10 PM, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On Jan 21, 2008 1:08 PM, Mike Kienenberger [EMAIL PROTECTED] wrote:
If something was publicly released as 1.2.1 already, then -- even if
it was pulled -- please do not release 1.2.1 again.
it wasn't released. Just
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
On Dec 20, 2007 10:11 AM, Simon Kitching [EMAIL PROTECTED] wrote:
This problem
:
Mike Kienenberger [EMAIL PROTECTED] schrieb:
Can't you do something like this to force the rt.jar to be 1.4?
http://java.sun.com/j2se/1.5.0/docs/tooldocs/windows/javac.html
% javac -target 1.4 -bootclasspath jdk1.4.2/lib/classes.zip -extdirs
OldCode.java
Yep. However that cannot be put
+1
On Dec 5, 2007 1:46 PM, Andrew Robinson [EMAIL PROTECTED] wrote:
Lets make the myfaces commons JSF API an official vote so we can have
a fixed time frame on this decision
+1 [ ] -- make JSF 1.2 the minimum requirement for the new myfaces
commons project
+0 [ ] -- you don't mind
At least in terms of the validators/converters/etc (non-api) parts of
commons, it is not intended that Tobago or any other project depend on
these. These are additional components made available to the end
users. So it's true that some small subset of Tobago users won't be
able to use it.
If you're going to support 1.1, support 1.4. Otherwise, just stick
with JSF 1.2.
I know where I do my primary JSF work, the major holdup has been JDK
1.5, which was only recently adopted, not JSF 1.2, per se.
I'm personally good with JSF 1.2 only, though, for this new project.
On Dec 3, 2007
;
/**
* @author Mike Kienenberger (latest modification by $Author: mlk $)
* @version $id$
*/
public class SortableHtmlDataTable extends HtmlDataTable
{
private static final Log log =
LogFactory.getLog(SortableHtmlDataTable.class);
public static final String COMPARATOR_FACET_NAME = comparator
the HtmlDataTable
component still uses SortableModel class to set the current sort column.
Wouldn't be normal to use BaseSortableModel class to allow extensibility?
Thanks.
Mike Kienenberger wrote:
As a first step in this process, I've separated SortableDataModel into
SortableDataModel
For html, I think we should continue to render .
For xhtml, we should render amp;
On Nov 21, 2007 7:37 AM, Manfred Geiler [EMAIL PROTECTED] wrote:
Please have a look at
http://issues.apache.org/jira/browse/MYFACES-1774
Do you think there is a problem with generally rendering amp; instead of
Please open a JIRA issue and attach your changes as a unified diff patch.
-Mike
On Nov 20, 2007 9:47 AM, Vorobjov, Dmitriy (DB) [EMAIL PROTECTED] wrote:
Guys,
I implemented TODO null-check for Weblogic, that tries to initialize
Servlet before ContextListener in FacesServlet class
Type: Bug
Components: JSR-127
Affects Versions: 1.1.5
Reporter: Mike Kienenberger
Priority: Minor
h:commandLink cannot have onclick attribute in tld file for JSF 1.1.
I just compared the tlds for MyFaces Core and JSF RI 1.1.
Apparently RI 1.1 doesn't support
[
https://issues.apache.org/jira/browse/MYFACES-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539681
]
Mike Kienenberger commented on MYFACES-1757:
Pointer to JSF RI issue, thanks to Ryan Lubke
https
Well, I think there's probably enough difference between the two goals
that we do need to separate projects, even though it contributes to
the Yet Another MyFaces Subproject quagmire. At least it's a step
in the right direction since we're looking at merging common code
rather than futher
We're discussing two completely different concepts here.
One is an api for writing new components. For component developers.
One is a library of common renderkit-independent components for use in
JSF applications. For application developers.
Attempting to combine them is going to shortchange
[
https://issues.apache.org/jira/browse/TOMAHAWK-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12538835
]
Mike Kienenberger commented on TOMAHAWK-1115:
-
The resistance was due to the lack of code generation
From what little I understand of maven, this looks like a good idea.
However, I think that with the proposal of a MyFaces Basics/Commons
project and a MyFaces Facelets project, that Tomahawk restructuring
should wait a few days. I'm still not seeing any consensus on what
these projects are
Note: pure speculation.
Possibly it's due to the misunderstanding that the #{blah} part of
the string is the EL expression.
Any string is an EL expression, and #{} is simply one operator that
can be used in that string. So #{a} text #{b} text #{c} is one EL
expression, not three.
On 10/30/07,
I don't think there's any hard rule that all projects have to be
prefixed with MyFaces.
But then, I also don't have any problem with it being associated with
Tomahawk or MyFaces (in the name).
On 10/29/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
I agree that MyFaces Basics is too
Should this also include myfaces-commons? I would expect Tomahawk to
build on myfaces-commons especially now that we're talking about
putting the common programming utilities into it, but I don't know if
that means it should be part of the Tomahawk super-project.
Second, JSF 1.1 requires jdk
Yes, this is perhaps another reason why this might best be placed
under Tomahawk.
We already have a Tomahawk sandbox in place for both Jdk 1.5 and
pre-1.5. Once a sandbox component is ready for promotion, part of
the evaluation could be deciding if it should go into the
works-with-anything
, Mike Kienenberger [EMAIL PROTECTED] wrote:
I think we're starting to confuse the focus here.
There's a difference between common components that can be used with
any JSF project, and common programming utilities, many of which may
be renderkit (like html) specific.
I'm ok with common
, Mike Kienenberger [EMAIL PROTECTED] wrote:
I have another question.
Why were these three converters checked into Tomahawk with absolutely
no discussion and nothing going through the sandbox first?
I search my mail archives for AtomicLongConverter and the ONLY
reference
And in case you somehow missed the other messages (which is why
Matthias started this thread), I've now reverted this from Tomahawk
due to Java 1.5 dependencies (and a lack of discussion beforehand).
For now, I'd recommend either committing it to sandbox15 or to MyFaces 1.2.
On 10/26/07, Dennis
No, it's not. There are components in Tomahawk that depend on
javascript. There are components in tomahawk that depend on MyFaces
core (aliasBean). There are components in Tomahawk that depend on
dojo. There are components in Tomahawk that depends on the MyFaces
form.
Right now, Tomahawk
project (who would be the judge of that, btw?), what do I need to do to
get it there? Since I am not a regular contributor, I suspect I can't
just check it in :), so what is the proper process?
Thanks.
Val
On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote
I have another question.
Why were these three converters checked into Tomahawk with absolutely
no discussion and nothing going through the sandbox first?
I search my mail archives for AtomicLongConverter and the ONLY
reference to it is the commit itself.
-Mike
On 9/16/07, [EMAIL PROTECTED]
Once I get back to JSF work, I'd happily contribute to a MyFaces
Facelets project. As I've said in years past, I don't know how to
set up a maven project, but once someone set up the infrastructure for
such a project, I'd be able to help with the rest.
The same goes for the MyFaces commons
Yes, wouldn't that have to be the case? Otherwise, A.jar and B.jar,
created by two independent groups, might use the same version id
without realizing it, and thus break a project depending on both of
them.
On 10/24/07, Martin Marinschek [EMAIL PROTECTED] wrote:
The stream identifier will
+1
:-)
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Lets start up the long awaited MyFaces Commons project.
The aim of this project will be to contain all stuff which do not belong
to a component.
[ ] +1 yea, lets start
[ ] +0
[ ] -1 no, for those reasons .
I'll do
Actually, let's clarify this to be all the stuff which is not
renderkit-specific.
Ie, if the validator/component/converter/other can be used with any
reasonable[1] combination of
JSF_RI/MyFacesCore/Tomahawk/Tobago/Trinidad/IceFaces/RichFaces/PortletBridge,
then it should be available here.
[1]
+1.
I'd suggest tomahawk-facelets[.jar] as the name since that's what it
is. The versioning should match Tomahawk's versioning, and hopefully
we'll release a new version each time Tomahawk is released.
On 10/24/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
Hi!
Lets start up a MyFaces
renderkit-specific projects can take advantage of what's available.
On 10/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Moving this out of the vote thread.
On 10/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0
Moving this out of the vote thread.
On 10/24/07, Paul Spencer [EMAIL PROTECTED] wrote:
1) Will their be a JSF version specific version, i.e. commons_1.2 and
commons_2.0?
I'd say yes, if it makes sense to do so.
2) What are some of the module will you be moving into the project(s)?
Some of
Why wouldn't aliasBean work as a commons project component? I
haven't looked at the implementation, but at first glance of the docs,
it doesn't seem to do anything renderkit-specific. I looked at the
renderer implementation and it simply looks like its being used as a
callback hook back into
It would definitely be a Tomahawk thing rather than a MyFaces Core change.
I haven't looked at your architecture in detail, but trying to wrap a
validator or converter is problematic, at least under JSF 1.1 + jsp.
It will probably work for JSF 1.2 or JSF 1.1 with facelets, though, if
I remember
and
aliasBeanScope. I don't think this special handling is included into
RI.
Regards,
Volker
2007/10/24, Mike Kienenberger [EMAIL PROTECTED]:
Why wouldn't aliasBean work as a commons project component? I
haven't looked at the implementation, but at first glance of the docs,
it doesn't
/24/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
+1.
I'd suggest tomahawk-facelets[.jar] as the name since that's what it
is. The versioning should match Tomahawk's versioning, and hopefully
we'll release a new version each time Tomahawk is released.
On 10/24/07, Mario Ivankovits
I misread Mario's original scope for this proposal. I don't have any
issues with it being more inclusive than tomahawk taglibs. My
apologies to Andrew.
If you are one of the people voting against a facelets subproject
containing tomahawk taglibs, does this mean you are volunteering to
On 10/24/07, Val [EMAIL PROTECTED] wrote:
I handled the addition of a converter or validators into the wrapper by
having my custom tag push a dummy UIInput tag onto the tag stack that
UIComponentTag uses and then having the wrapped converter/validators set
themselves up in the dummy component
it there? Since I am not a regular contributor, I suspect I can't
just check it in :), so what is the proper process?
Thanks.
Val
On Wed, 2007-24-10 at 15:54 -0400, Mike Kienenberger wrote:
On 10/24/07, Val [EMAIL PROTECTED] wrote:
I handled the addition of a converter or validators
401 - 500 of 1572 matches
Mail list logo
