Re: Examples directory
Sounds great. I think we've got plenty of improvements to make a release very worthwhile! -- Adam On 5/3/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hey Adam, I am planing to run another release end of may / beginning of June. Than I'll fix the assembly and example issue. Any objections ? -M On 4/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 4/28/07, Adam Winer [EMAIL PROTECTED] wrote: @Matthias: I think you added the examples directory, and put the trinidad-demo in as an example. However - this means we currently have two copies of the trinidad-demo, one in examples and one at top level. Also, trinidad-examples is not built by default, as it's not one of the modules in the trinidad/pom.xml. Shouldn't we only have one copy of all the demos? I've been making modifications here and there, and always just to the old trinidad-demo. yes! I did it for the release and never had the chance to manage the update on the trunk. For now it's not usfull in the 1.2 branch and old in the trunk... I hope that I am able to update the stuff in trunk during ApacheCon. For the branch 1.2-xxx just, remove it, it's not used. My goal is that the trinidad-examples will be the source for all examples (like a blank and the demo, ...). -Matthias I'm noticing this because on the 1.2 branch, the whole trinidad-examples tree is still pointing at the trunk versions of all the code, myfaces-1.1.5 implementation, etc. -- Adam -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: client id problem
On 4/30/07, Anahide Tchertchian [EMAIL PROTECTED] wrote:
Hi,
This is on the 1.1 trunk.
There is no UIComponent.getContainerClientId() method
in JSF 1.1. It was added in 1.2, and I'm pretty sure our
1.2 code properly calls it. The trunk is strictly 1.1. So
I don't think you've found a bug.
I'd be happy to test the 1.2 branch if I could find a maven repository
for it :)
You have to build it yourself, I'm afraid. Ongoing problems
with continuum have prevented us from putting it in a maven
repository.
-- Adam
Adam Winer a écrit :
Is this on the 1.2 branch or the 1.1 trunk?
-- Adam
On 4/25/07, Anahide Tchertchian [EMAIL PROTECTED] wrote:
Hi,
I noticed that trinidad components client ids are not set up correctly
when used inside a naming container that redefines its children client
ids.
I believe this could be fixed applying the following changes, which is
not very visible as the default implementation returns getClientId when
calling getContainerClientId.
$ svn di
./src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
Index:
src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
===
---
src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
(revision 532384)
+++
src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
(working copy)
@@ -270,7 +270,7 @@
{
if (containerComponent instanceof NamingContainer)
{
-clientId = (containerComponent.getClientId(context) +
+clientId = (containerComponent.getContainerClientId(context) +
NamingContainer.SEPARATOR_CHAR +
clientId);
break;
Do you think this could be made available for the next version?
Thanks,
--
Anahide Tchertchian, Nuxeo
Mail: [EMAIL PROTECTED] - Tel: +33 (0)1 40 33 79 87
http://www.nuxeo.com - http://www.nuxeo.org
Re: [process...] Trinidad moving to MyFaces
I'm also reluctant to spin us off into a separate e-mail list. I do think we'll want a [Trinidad] convention for posts though. -- Adam On 4/27/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I think Myfaces subprojects should be using the existing user and dev lists. Otherwise, you're getting into the situation where that Martin van den Bemt warned about where you're off in your own little world without visibility to the entire MyFaces community. On 4/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, one more thing I'd like to get your feedback. Regarding the mailing list, what should we do? Using users@ and dev@ myfaces , or creating new lists, like [EMAIL PROTECTED] For the Jira, only a rename is needed. ADFFACES = TRINIDAD Any comments, objections `? -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Examples directory
@Matthias: I think you added the examples directory, and put the trinidad-demo in as an example. However - this means we currently have two copies of the trinidad-demo, one in examples and one at top level. Also, trinidad-examples is not built by default, as it's not one of the modules in the trinidad/pom.xml. Shouldn't we only have one copy of all the demos? I've been making modifications here and there, and always just to the old trinidad-demo. I'm noticing this because on the 1.2 branch, the whole trinidad-examples tree is still pointing at the trunk versions of all the code, myfaces-1.1.5 implementation, etc. -- Adam
FastMessageFormat to public API?
Trinidad has a FastMessageFormat class in the impl that is a partial replacement for MessageFormat - and, last I tested, far faster for the typical case of use-once-and- throw-away scenario that comes up in webapps a lot. Any comments on moving it from o.a.m.trinidadinternal.share.util.FastMessageFormat to o.a.m.trinidad.util.FastMessageFormat? (It's actually already been moved for awhile, but is package-private in trinidad-api). -- Adam
Re: SVN - move
In general, no, but I got a bit more interested when you said the layout was going to change - how so? Did I miss an e-mail? Also, what about the branches - I'm very much in need of the 1.2 branch. -- Adam On 4/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi, I am planing to move the SVN to myfaces' SVN. Over the weekend. Any objections ? -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: client id problem
Is this on the 1.2 branch or the 1.1 trunk?
-- Adam
On 4/25/07, Anahide Tchertchian [EMAIL PROTECTED] wrote:
Hi,
I noticed that trinidad components client ids are not set up correctly
when used inside a naming container that redefines its children client ids.
I believe this could be fixed applying the following changes, which is
not very visible as the default implementation returns getClientId when
calling getContainerClientId.
$ svn di
./src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
Index:
src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
===
---
src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
(revision 532384)
+++
src/main/java/org/apache/myfaces/trinidad/component/UIXComponentBase.java
(working copy)
@@ -270,7 +270,7 @@
{
if (containerComponent instanceof NamingContainer)
{
-clientId = (containerComponent.getClientId(context) +
+clientId = (containerComponent.getContainerClientId(context) +
NamingContainer.SEPARATOR_CHAR +
clientId);
break;
Do you think this could be made available for the next version?
Thanks,
--
Anahide Tchertchian, Nuxeo
Mail: [EMAIL PROTECTED] - Tel: +33 (0)1 40 33 79 87
http://www.nuxeo.com - http://www.nuxeo.org
Re: ADFFACES-466 - Issues in change persistence framework code
I added one comment to the issue tracker: this patch adds global synchronization to the application of changes. This seems higly excessive! The responsibility for synchronization should belong on the implementation of ChangeManager.getComponentChanges(), not on its use. If you used a CopyOnWriteArrayList for these lists, wouldn't that be sufficient? -- Adam On 4/26/07, Srinathreddy Komatireddy [EMAIL PROTECTED] wrote: Hi, Can someone please review ADFFACES-466 https://issues.apache.org/jira/browse/ADFFACES-466. I have submitted a patch describing the issues and changes. -Thanks, Srinath K
Re: Dependencies ?
I believe our JSF 1.2 code requires Shale Test 1.0.4, not 1.0.3. -- Adam On 4/24/07, Piyush Hari [EMAIL PROTECTED] wrote: Thanks for the reply Mike but this did not solve the problem. I had to include javaee.jar which I got when I installed Java EE 5 SDK on my machine. Also,I removed Myfaces jars and now just use JSF 1.2 Jars now. Thanks for that tip. Then, I had to include a few other JARS like shale-test etc. Now, when I run junit tests from command prompt after copying the necessary testScripts and golden files in the working directory, all the tests fail. Any leads ? Here is the command line followed by the stacktrace : C:\Java\jdk1.5.0_09\bin\java -Dtrinidad.renderkit.fulltests=lenient -Dorg.apache.myfaces.trinidad.ForceGolden=false -Dtrinidad.renderkit.scripts=C:/Temp/coverage/testScripts/ -Dtrinidad.renderkit.golden=C:/Temp/coverage/golden/ -Dtrinidad.renderkit.failures=C:/Temp/coverage/target/test-failures/ -cp c:\Temp\trinidad-impl\trinidad-impl.jar; c:\Temp\trinidad-impl\trinidad-impl-test.jar; c:\Temp\trinidad-impl\jsf-api.jar; c:\Temp\trinidad-impl\jsf-impl.jar; c:\Temp\trinidad-impl\activation-1.1.jar; c:\Temp\trinidad-impl\commons-beanutils-1.7.0.jar; c:\Temp\trinidad-impl\commons-codec-1.3.jar; c:\Temp\trinidad-impl\commons-collections-3.1.jar; c:\Temp\trinidad-impl\commons-digester-1.6.jar;c c:\Temp\trinidad-impl\commons-el-1.0.jar; c:\Temp\trinidad-impl\commons-lang-2.1.jar; c:\Temp\trinidad-impl\commons-logging-1.0.4.jar; c:\Temp\trinidad-impl\jsf-facelets-1.1.11.jar; c:\Temp\trinidad-impl\jstl-1.1.2.jar; c:\Temp\trinidad-impl\mail-1.4.jar; c:\Temp\trinidad-impl\myfaces-api-1.1.5.jar; c:\Temp\trinidad-impl\myfaces-impl-1.1.5.jar; c:\Temp\trinidad-impl\trinidad-api-test.jar; c:\Temp\trinidad-impl\trinidad-api.jar; c:\Temp\trinidad-impl\javaee.jar; c:\Temp\trinidad-impl\shale-test-1.0.3.jar; c:\junit\junit3.8.1\junit.jar; C:\emma-2.0.5312\lib\emma.jar; junit.textui.TestRunner org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitTest ** stack trace for table.xml golden file ** There were 7 errors: 1) table-minimal(org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase $RendererTest)java.lang.UnsupportedOperationException at javax.faces.context.FacesContext.getELContext(FacesContext.java:136) at javax.faces.component.UIViewRoot.setLocale(UIViewRoot.java:888) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitBootstrap.crea teUIViewRoot(RenderKitBootstrap.java:49) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseT est.setUp(RenderKitTestCase.java:162) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseT est.run(RenderKitTestCase.java:143) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$Rende rerTest.run(RenderKitTestCase.java:307) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase.run(R enderKitTestCase.java:92) 2) table-minimalIE(org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCa se$RendererTest)java.lang.IllegalStateException: Trying to attach RequestContext to a thread that already had one. To enable stack traces of each RequestContext attach/release call, enable Level.FINEST logging for the class org.apache.myfac es.trinidad.context.RequestContext at org.apache.myfaces.trinidad.context.RequestContext.attach(RequestCont ext.java:473) at org.apache.myfaces.trinidadinternal.renderkit.MRequestContext.init( MRequestContext.java:47) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseT est.setUp(RenderKitTestCase.java:156) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseT est.run(RenderKitTestCase.java:143) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$Rende rerTest.run(RenderKitTestCase.java:307) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase.run(R enderKitTestCase.java:92) 3) table-minimalIERtl(org.apache.myfaces.trinidadinternal.renderkit.RenderKitTes tCase$RendererTest)java.lang.IllegalStateException: Trying to attach RequestCont ext to a thread that already had one. To enable stack traces of each RequestCont ext attach/release call, enable Level.FINEST logging for the class org.apache.my faces.trinidad.context.RequestContext at org.apache.myfaces.trinidad.context.RequestContext.attach(RequestCont ext.java:473) at org.apache.myfaces.trinidadinternal.renderkit.MRequestContext.init( MRequestContext.java:47) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseT est.setUp(RenderKitTestCase.java:156) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseT est.run(RenderKitTestCase.java:143) at org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$Rende rerTest.run(RenderKitTestCase.java:307) at
Re: [Graduation] Trinidad voted out of Incubator
Woo-hoo! Thanks to all the contributors. Are we also going to move the issue list over? -- Adam On 4/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Dear Trinidad community, The Trinidad PPMC is pleased to let you know, that Trinidad has been voted out of the Apache Incubator. We got 12 binding +1 votes by the Apache Incubator PMC, and two more non-binding by the Incubator community (see [1]). Trinidad graduates as a subproject of the Apache MyFaces community. The next steps are allocating a SVN folder w/in the MyFaces SVN repo. The mailing lists will also be moved to myfaces. I think I can speak for all of us, that we have 13 interesting month (11,5 with sources in the SVN ;)) behind us, and we are happy to announce that leaving the Incubator has become reality. Thanks to all of you for participating in this community. Without that this never had been possible. This project has proven that Apache-style OpenSource (community-focused) is a good choice! -Matthias [1] -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Client-side validation - enhance to match server-side
Sorry - I've been wanting to have a look at it, but been generally swamped. Hopefully soon... -- Adam On 4/20/07, Danny Robinson [EMAIL PROTECTED] wrote: Does anyone have any feedback on this patch? I don't expect it is perfect or complete, but I'd like to understand if this is the approach you'd expect for implementing this feature. https://issues.apache.org/jira/browse/ADFFACES-391 On 3/16/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, I've posted an initial patch so client-side validation matches server-side here: https://issues.apache.org/jira/browse/ADFFACES-391 Feedback gratefully received. Description: Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION /param-name param-valuetrue/param-value /context-param [ Show » https://issues.apache.org/jira/browse/ADFFACES-391 ] Danny Robinsonhttps://issues.apache.org/jira/secure/ViewProfile.jspa?name=dannyjrobinson [16/Mar/07 08:59 AM] Attached patch file will provide an alternative client-side validation mode where message layout and appearance exactly follows the server-side mode. It renders hidden (skinned) elements that are dynamically populated with error text and displayed if c/s validation fails for a given component. The 'X' icon is also dynamically displayed. This works for input fields rendered inside or outside of panelForm. It contains certain changes to FormRenderer so that is will render a different validation method depending on the setting below. _multiValidate method was modified so it returns a 2d array of id, message which is then processed by either _validateAlert() or _validateInline. FormRenderer now uses the return value of the above methods to determine if submit can occur. Outstanding features: * Public js method that can be added to onblur (eg. onblur=validateField(this);) to enable immediate validation of fields. * Test with fields in tables I guess this setting would be more at home in trinidad-config.xml though. context-param param-name org.apache.myfaces.trinidadinternal.renderkit.INLINE_JS_VALIDATION/param-name param-valuetrue/param-value /context-param On 3/1/07, Adam Winer [EMAIL PROTECTED] wrote: Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete -- Chordiant Software Inc. www.chordiant.com -- Chordiant Software Inc. www.chordiant.com
Re: MessageBundleTest._validateBundleParams
Ah, I see. It gives warnings for missing keys, but errors
when the set of parameters don't match up. Yeah,
I guess disabling it is the simplest answer.
-- Adam
On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
It fails
Tests run: 1, Failures: 1, Errors: 0, Time elapsed: 0,031 sec
testBundles(org.apache.myfaces.trinidad.resource.MessageBundleTest)
Time elapsed: 0,031 sec FAILURE!
[ stdout ] ---
[ stderr ] ---
[ stacktrace ] ---
junit.framework.AssertionFailedError: Error while testing bundle
MessageBundle_ar
Place holders mismatch in key
org.apache.myfaces.trinidad.validator.DateTimeRangeValidator.MAXIMUM_detail
Default bundle params {2}
MessageBundle_ar params {2} {1}
at junit.framework.Assert.fail(Assert.java:47)
at
org.apache.myfaces.trinidad.resource.MessageBundleTest._validateBundleParams(MessageBundleTest.java:237)
at
org.apache.myfaces.trinidad.resource.MessageBundleTest._validateBundle(MessageBundleTest.java:142)
Do you mind to disable it for now ?
I'll file a bug that it's disabled, I'll enable it, when the
translations arrive.
On 4/19/07, Adam Winer [EMAIL PROTECTED] wrote:
I think the test should just be dumping warnings, not failing.
-- Adam
On 4/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
when putting the *new* messages in place, I noticed that this test fails:
MessageBundleTest._validateBundleParams()
That is because only the English messages are in a good shape, all
translations, like German, Chinese and whatnot aren't updated yet.
Two possible steps I am seeing:
-commit all in once (English and translated)
-turn off the test (for now ;-))
What is your take on that?
Thx,
Matthias
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: Fwd: [jira] Reopened: (ADFFACES-445) Converters not working , Javascript error occuring on submit
I can't explain why the heck you're getting the HTML
you are... lots and lots of things are just bizarre
in the HTML output I see. How are you capturing this?
You should just be using View/Page Source,
copying and pasting the results.
Do you have any servlet filters installed? Anything
weird about your setup *at all*?
-- Adam
On 4/17/07, Safurudin Mahic [EMAIL PROTECTED] wrote:
Adam,
my trindad-config.xml does not have the client-validation-disabled
entry. Just for fun, I tested by adding this entry to the config. The
JavaScript error (and validation) disappears - the framework is
producing old-fashioned validation errors with appropriate messages upon
postback. This means that there is some setting blocking Trinidad from
generating that last piece of JavaScript.
For this particular project, I guess I can manage without the JavaScript
validation, but this doesn't solve the underlying problem. Are there any
other settings in either web.xml, faces-config or trindad-config which
may affect that the required JavaScript isn't generated as supposed to?
-- Safi
Adam Winer skrev:
Safurudin,
Trinidad HTML source should always have something like:
scriptvar _reset_idJsp1Names=[source];/scriptscriptfunction
__idJsp1Validator(){return true;}var _idJsp1_SF={};/script
... near the end. Yours doesn't. By any chance, do
you have:
client-validation-disabledtrue/client-validation-disabled
in your trinidad-config.xml? If so, does the problem go away when
you remove it?
-- Adam
On 4/17/07, Safurudin Mahic [EMAIL PROTECTED] wrote:
Adam,
I wasn't sure how to do the Firebug breakpoint thingy,
I've attached the generated HTML code instead.
-- Safi
Adam Winer skrev:
Safurudin,
I still can't reproduce this. What you're doing should work
without hitch; you're not supposed to have to code anything
differently. With the latest trunk, Firefox 2.0.0.3, and the following
page:
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
jsp:directive.page
contentType=text/html;charset=utf-8/
f:view
tr:document
tr:form id=form1
tr:inputText value=#{data.int}/
tr:outputText value=#{data.int}/
tr:commandButton text=Submit/
/tr:form
/tr:document
/f:view
/jsp:root
... everything works fine for me.
To get to the bottom of this, I'll need your help to
look into the Javascript and see what's going wrong.
For example, install Firebug and put a breakpoint
in this code. Or, if you can't do that, maybe e-mail
me the HTML generated by this simple page?
The lines where you're getting the error are:
var converter=eval(converterConstructor);
try{
value=converter.getAsObject(value,label);
}
catch(e)
{
converterError=true;
if(firstFailure)
{
_setFocus(currInput);
firstFailure=false;
}
var errorString1=e.getFacesMessage().getDetail();
...
}
... and if e doesn't have a FacesMessage, that means
there *is* an exception being thrown, but it's somehow not
of the right type. Which is very, very strange - converter
here should be an instance of TrIntegerConverter,
which only throws TrConverterException.
If anyone else on the list has reproduced this bug
and can help out, please do. :)
-- Adam
-- Forwarded message --
From: Safurudin Mahic (JIRA)
[EMAIL PROTECTED]
Date: Apr 15, 2007 3:37 AM
Subject: [jira] Reopened: (ADFFACES-445) Converters not working ,
Javascript error occuring on submit
To: [EMAIL PROTECTED]
[
https://issues.apache.org/jira/browse/ADFFACES-445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Safurudin Mahic reopened ADFFACES-445:
--
With a clean browser cache - using both Firefox (2.0.3) and IE7,
latest trunk I get this error on both the
convertValidate/convertValidate.jspx
and a simple file with a single tr:inputText component, bound to an
integer/long value in a backing bean.
The simple file looks something like this:
tr:document
tr:form id=form1
tr:inputText value=#{TestBean.intVal}/
tr:outputText value=#{TestBean.intVal}/
tr:commandButton text=Submit action=success/
/tr:form
/tr:document
This causes the earlier mentioned JavaScript error, which I suspect
comes from that Trinidad is trying to validate the field with
JavaScript before submittal of the form. But when the JavaScript
produces an error, the form is never submitted.
However, I see that when I attach a converter to the tr:inputText
component, something like tr:inputText value=#{TestBean.intVal}
converter=javax.faces.convert.IntegerConverter
component, this
seems to resolve the issue in my simple form.
The issue with the demo application still remains though,
convertValidate/convertValidate.jspx
Re: [XRTS] overhaul of the NumberConverter messages (their details)
Me too. The only downside is that these examples
are a performance hit (a significant one, last time
I profiled inputDate). NumberConverter is probably
more lightweight than DateConverter.
-- Adam
On 4/11/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
That sounds great to me.
- Jeanne
Martin Marinschek wrote:
Well, that's certainly a good idea!
regards,
Martin
On 4/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEllo,
currently we have something like:
The value {1} is not a valid currency value.
or
The value {1} is not a valid percentage value.
as the detail message for the FacesMessage. The DateTimeConverter is
much nicer to the user. It is providing an example, using the
right format/pattern.
I'd like to add something like that to the NumberConverter as well.
Thanks,
MAtthias
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: VOTE graduation (was Re: Next steps? (was Re: Is trinidad ready for graduation ?))
[X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... On 4/11/07, Jeanne Waldman [EMAIL PROTECTED] wrote: [X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... Simon Lessard wrote: [X] graduate as a subproject of the Apache MyFaces community [ ] graduate as a TLP [ ] not ready to graduate, because... On 4/11/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 4/11/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [X] graduate as a subproject of the Apache MyFaces community Craig PS: Note that binding is only relevant on release votes, where it's a PMC member doing the voting. For procedural issues (like this one), all committers are equal.
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
If there was an idea to split MyFaces into an implementation half and a component set half, each as separate TLPs, then I'd see your point - but as it is, MyFaces the TLP is both an implementation and (currently) 2 component sets. -- Adam On 4/10/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Sorry for the one in all reply.. Ok, let's switch perspective's here. MyFaces (the codebase) is a JSF implementation. Tomahawk and Trinidad are JSF component sets. I am not comparing the possible overlap of the component sets, I am focussing on the possible lack of overlap in community of the JSF implementation and the component sets. Different goals, different users and different developers (although the last is not yet the case, it is most likely someone interested in components is not interested in coding on the JSF implementation). Just playing bad cop here though, to hopefully prevent this situation (if you are aware of these signs you can watch out for it) Not going to vote -1 on a move to MyFaces. Mvgr, Martin
Re: [Fwd: Re: return an Iterator vs a List]
I don't think there's that much reason not to return
a List. All I'm saying is that if you had an API
that was Iterator, and your desire was to support
the fun SE 5 for construct, then Iterable is the
simplest change. The question then is why the
original API was ever Iterator, and if it should
have been List, or Collection, etc.
I'm not thrilled with exposing List if you think that
you might someday want it to be a Set - Collection
is safer in that regard.
-- Adam
On 4/9/07, Blake Sullivan [EMAIL PROTECTED] wrote:
Adam,
Actually the reason for the switch to List versus Iterable would be for
general convenience of developers consuming the api (with efficiency a
much smaller issue).
Which methods on java.util.List do you think are providing too broad of
a contract? Do you believe that returning a List is limiting the
implementations choices severely enough that it outweighs the
convenience of using a Collection class?
-- Blake Sullivan
Jeanne Waldman wrote:
three out of six
Original Message
Subject: Re: return an Iterator vs a List
Date: Wed, 4 Apr 2007 15:42:17 -0700
From: Adam Winer [EMAIL PROTECTED]
Reply-To: adffaces-dev@incubator.apache.org
To: adffaces-dev@incubator.apache.org
References:
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
If the only reason is to enable the fun new for syntax,
then we should change the type from Iterator to Iterable,
instead of List. List is a much larger contract.
-- Adam
On 3/28/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I'm in the Skinning StyleNode code and I see that the 'get' methods
return Iterators
from the good ol' days.
It seems to me that it is better if they just return Lists so the code
that iterates over
the values is cleaner using 5.0's for(String foo : yyy) construct.
Does anyone see why I wouldn't want these to return List instead of
Iterator?
Here's a code snippet. Thanks, Jeanne
--
public IteratorIncludePropertyNode getIncludedProperties()
{
if(_includedProperties == null)
{
ListIncludePropertyNode list = Collections.emptyList();
return list.iterator();
}
else
return (Arrays.asList(_includedProperties)).iterator();
}
/**
* Gets the properties specified by this node's parent that should be
* ignored. This method will return an empty iterator if
* [EMAIL PROTECTED] #isInhibitingAll()} returns codetrue/code
*
* @return an iterator over the properties that should be ignored, an
* empty iterator if all properties should be.
*/
public IteratorString getInhibitedProperties()
{
if(_inhibitedProperties == null)
{
ListString list = Collections.emptyList();
return list.iterator();
}
else
{
return _inhibitedProperties.iterator();
}
}
Re: ADFFACES-191
Martin, Just applied it. Sorry for the long delay. FYI, the patch works on Safari too. -- Adam On 4/4/07, Martin Koci [EMAIL PROTECTED] wrote: Hello, can anybody review ADFFACES-191? We are using suggested patch in a production environment without problems: windows, linux; firefox 1.5.X or 2.0.X on both OS, IE 6 and 7 on Windows. Regards, Martin Koci
Re: Next steps? (was Re: Is trinidad ready for graduation ?)
On 4/7/07, Mike Kienenberger [EMAIL PROTECTED] wrote: I'm in favor of MyFaces for Trinidad. I would like to see Trinidad as the basis for Tomahawk JSF 1.2. However, if there is no interest in merging Tomahawk and Trinidad, then going with a TLP would be better. Right now, Tobago is in the state you described below -- You're either using Tobago (and no other component set), or you're using Tomahawk and other component sets. It's next to impossible to have oversight over both projects since Tobago is mutually-exclusive of other component sets. At one point, the Tobago people were interested in making Tobago more compatible with Tomahawk and other component sets, but discussion on how that would happen ever materialized beyond my initial questions. FWIW, I think Trinidad is more compatible with Tomahawk then Tobago is... they don't work perfectly together, but I'd very much like to see the incompatibilities resolved. Whether we should merge the components - I don't know. But I do think we could get some code sharing and common framework work applied. (State saving, skinning, and client-side validation come to mind). So, I'd prefer a subproject to a TLP. -- Adam On 4/7/07, Martin van den Bemt [EMAIL PROTECTED] wrote: +1.. Thing to decide now is TLP or as subproject of MyFaces. Main thing is focus to decide on what to do : - People on MyFaces equally care about and work on Trinidad - People on Trinidad equally care about MyFaces MyFaces == the code base, not the TLP project. People working on Trinidad wouldn't necessarily be interested in working on the MyFaces code base. Giving oversight in an umbrella project will get harder and harder over time, which in the end does end up in a fragmented PMC. Which means that people on the PMC just have focus on eg MyFaces, tomahawk, Tobago or Trinidad. If you are a on the PMC you should care about all of these subprojects. In short : I favor TLP. Mvgr, Martin Matthias Wessendorf wrote: on our march reports, Jukka was asking: snip Things to do before graduation? /snip checking the checklist (briefly) it looks like we are set ... -M On 3/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 3/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello Martin, your email states that this group should at least manage to get the release of the plugins out. I did. Currently this group is waiting for an approval to release the CORE as well. was approved and already released :-) One item, we need to check is Project ready to comply with ASF mirroring guidlines I will look at MyFaces, how we do it there, shouldn't be that big deal. posted to /www/people.apache.org/dis/incubator, as suggested here @GUMP: we use(d) continuum (was reseted currently) that should be ok?! What is your current thinking about this group? Start a vote? Fix the missing items? Wait for approval for CORE ? So, what is the next step ? A vote here on this list ? I think, we also need to run a vote on the MyFaces PMC, to accept Trinidad as one of their subprojects. I'll do that vote as well, when time comes ;-) -Matthias Thanks! Matthias On 2/10/07, Martin van den Bemt [EMAIL PROTECTED] wrote: In short : according to me they are.. Any feedback and additions appreciated.. On note : I like to see that at least the plugins get a release before we start a vote on dev (and I expressed below that you are targetting to have a release of core before leaving the incubator, although that could be a misunderstanding) If everyone agrees on dev, we start a vote on the incubator general list and after that on the MyFaces private list. Exit strategy probably needs to be discussed with the MyFaces crowd (like mailinglists) and they probably need to have votes on people on the trinidad ppmc list that are not yet on the MyFaces PMC (but that's up to the MyFaces PMC). I'll subscribe to the private myfaces list (in case you didn't know : I can as a member, which doesn't actually mean that I am on that PMC or have a binding vote there). The very long version : To determine if Trinidad is ready to leave the incubator I took http://incubator.apache.org/incubation/Incubation_Policy.html#Exiting+the+Incubator and tried to answer all the questions. The first 3 on that page are actually the last ones, since I am treating them more as general conclusions. Legal * All code ASL'ed Looking at https://issues.apache.org/jira/browse/ADFFACES-355 it is solved. Most important is that before the release everything is ok, so that check needs to be done before a release (eg by using RAT, mojo.codehaus.org is working on a maven2 plugin atm). * No non ASL or ASL compatbile dependencies in the code base Don't see any problems here (just
Re: JBoss Seam Trinidad integration
On 3/29/07, Peter Muir [EMAIL PROTECTED] wrote: Hi I've started doing some work on this. On 02/02/07, Adam Winer [EMAIL PROTECTED] wrote: (1) Page in data as necessary, automatically I'm not entirely sure how this is supposed to be done with the CollectionModel. As we're using JPA what we want is a something like: // build the query query.setFirstResult(10); query.setMaxResults(10); List list = query.getResultList(); // wrap the result list in a datamodel. but the CollectionModel isn't updated with paging information - it seems to be stored on the component. Any hints ;) Well, in theory, you'd do this semi-lazily: have a fetch size stored in the model (which, depending on what sort of caching you have available, might be a multiple of the row count on the component), and then on the first request for a particular row, fire the query off with a heuristic for setFirstResults() and the fetch size for setMaxResults(). The pain comes if you want to do this aggressively (e.g., before Render Response). (2) Report good permanent row keys, so that adding/removing rows gets picked up without any off-by-one errors. It should be possible to use the business key of the entity for this, just some problems arise as the EntityManager isn't always available. (3) Perform sorting directly on the model This works nicely - translating the sort criterion into an order by and an order by into a ListSortCriterion. Trinidad doesn't seem to support a ListSortCriterion with more than one element however (it just displays the little arrow for the first criterion)? Well, it's certainly great progress to support a single sort criterion. I do think we should have some UI support for at least displaying secondary sort criteria, even if there's nothing built in on tr:column for activating multiple sort criteria straight from the UI. -- Adam
Re: Problem with showOneAccordion
panelAccordion is rather badly broken, last I checked.
See http://issues.apache.org/jira/browse/ADFFACES-398
And the renderer code for panelAccordion, panelRadio,
panelChoice... shudder. Roughly speaking, everything
in org.apache.myfaces.trinidadinternal.renderkit.html.layout
needs to be rewritten.
-- Adam
On 3/28/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi again,
I've looked at the combined code for CorePanelAccordion and
UIXShowDetail and their renderers and I wonder why the code for doing
the disclosure/closure is spreaded out so much. Wouldn't it be better
to handle this in the detail and the parent components, and in the
renderer only do the rendering of the component? That should be
possible with the event system, right?
regards,
Martin
On 3/29/07, Martin Marinschek [EMAIL PROTECTED] wrote:
Hi *,
can anyone of the Trinidad core developers do me a favour and look at:
http://example.irian.at/trinidad-demo-20070328/faces/components/showOneAccordion.jspx
do you think the behaviour is what a user expects? I would not think
so... When I click on Panel 1 and then on Panel 2, I would suspect
Panel 2 to be opened afterwards, but it isn't.
I've added the following code to CorePanelAccordion to make this work again:
@Override
public void queueEvent(FacesEvent event) {
super.queueEvent(event);
// Deliver to the default ChartDrillDownEvent
if (event instanceof DisclosureEvent)
{
List li = this.getChildren();
for(int i=0; ili.size(); i++) {
UIComponent comp = (UIComponent) li.get(i);
if(comp instanceof UIXShowDetail) {
((UIXShowDetail) comp).setDisclosed(false);
}
}
}
}
but - this code will need to be restricted to take events only of
direct children, and only for showOneAccordions. Apart from this -
would you think this is the right approach for a fix?
regards,
Martin
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: VOTE RESULT (was Re: [vote] release of core (1.0.0-incubating))
On 3/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: got feedback from Noel, vote is closed. no release yet. Robert found some issues (almost caused by buggy maven plugins and already fixed here). The other one is the obfuscated JS files don't have the Apache license headers. Waiting on feedback from Robert. Ugh... the whole point of obfuscating is to eliminate unnecessary content in our downloads. It'd really bug me to add overhead to all of our pages to satisfy this legalism. Even worse, the Apache license would show up over and over again, since we append JS files at runtime. -- Adam Thx, Matthias On 3/16/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: sent out to the [EMAIL PROTECTED], to get the approval -M On 3/15/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi guys, thanks for participating on the vote. Here is the result: binding +1: -Bruno Aranda (Trinidad PPMC member / MyFaces PMC member) -Gabrielle Crawford (Trinidad PPMC member) -Simon Lessard (Trinidad PPMC member) -Martin van den Bemt (Mentor of Trinidad / Incubator PMC) -Matthias Wessendorf (Trinidad PPMC member / MyFaces PMC member) non-binding +1: -Matt Cooper (contributor) -Bernd Bohmann (MyFaces PMC) -1: none :) I'll bring up the vote on the [EMAIL PROTECTED] list soon. -Matthias On 3/15/07, Martin van den Bemt [EMAIL PROTECTED] wrote: +1 :) Mvgr, Martin Matthias Wessendorf wrote: Hey Martin, I just did an upload of those checksum files to: http://people.apache.org/~matzew/dist_trin_core/ so, now I would count your vote as a +1 The other thing (commons-logging), I'd like to check for the next release, ok? Thx, Matthias On 3/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: On 3/14/07, Martin van den Bemt [EMAIL PROTECTED] wrote: Sorry people for the late response.. -1.. Missing md5/sha1 checkum for tar.gz and zip (the dist_trin_core). If they are added and are ok, I am changing to +1.. haha! you got me :-) Thanks! Maybe wise to add a text that the binary dist is a complete distribution including sources (most of the time you see a separate release for source). No issues here with it all being in one dist though yes, I used the pattern from Tobago, so I followed it ;) Also I rather see incubating-example unpack in it's own directory (no blocker btw, just personal preference, since it messes up my unpacked dist package). Another question : Why is commons-logging version 1.0 included and not a later version ? well,... lemme check, perhaps dependency of a dependency ? :) I'll fix the md5/sha1 thing tomorrow and upload a new dist. -Matthias Mvgr, Martin Matthias Wessendorf wrote: Hi, I managed to get some release artifacts published to a stage repo. I used my private Apache account for that ([1]). Also there is a distribution available at [2]. Please take a look at the 1.0.0-incubating artifacts and vote if we should take these file to ask the Incubator PMC for approval [ ] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Matthias [1] http://people.apache.org/~matzew/stage_trin_core/ [2] http://people.apache.org/~matzew/dist_trin_core/ -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [Plugins] Obfuscator
It's very intentional that we do this - the whole idea is to remove the wasteful download of content to the user. It's especially relevant since we concatenate these files. Including the Apache header on each and every one of those will waste on the order of 13K of bandwidth! Ugh. Do the Apache rules really require this on 100% of files? If we're forced to do this, we'd have to put in some sort of runtime obfuscation, likely stripping opening comments on files, because the extra download penalty is unacceptable. -- Adam On 3/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hello, the obfuscator removes the Apache license headers from the JS files. That shouldn't be the case, and it looks like it will block the release of the CORE. Any ideas ? :-) Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Getting rid of an ugly assert usage
Yeah, that abuse of assert always bugged me.
-- Adam
On 3/15/07, Simon Lessard [EMAIL PROTECTED] wrote:
Hello all,
I would like to get rid of the following code snippet from
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.table.RowData and
make that usage forbidden in our coding conventions wiki, as it's really a
poor man's #ifdef __DEBUG and goes against the idea of assert not having
any
performance overhaul at runtime.
boolean assertEnabled = false;
assert assertEnabled = true;
...
if (assertEnabled)
{
// make sure prev operation was get:
assert (_currentRowSpanState == 2);
_currentRowSpanState = 0; // indicate that we have reset the rowspan
}
Any objection?
~ Simon
Re: [NumberConverter] percentage vs. percent
Ah, OK. Well, that makes more sense - I was surprised that we'd picked a different constant. So, let's stay with percent, of course. -- Adam On 3/14/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: looks like the TLD for the convertNumber is wrong. the javax.faces uses only percent (both RI and MyFaces) So, they should change the doc to not say types... percentage -M On 3/14/07, Adam Winer [EMAIL PROTECTED] wrote: Yes, definitely. We should allow both. -- Adam On 3/13/07, Gabrielle Crawford [EMAIL PROTECTED] wrote: How strange. I think we should allow 'percentage' so that people can switch from the spec one without confustion. Thanks, Gab On 3/13/2007 7:15 AM, Matthias Wessendorf wrote: Hi, the Trinidad NumberConverter, which is an extension of the javax.faces NumberConverter doesn't allow type=percentage, which is a value of the spec. To me, percent sounds more natural as a value to choose, but shouldn't we at least allow percentage as a valid value for the tr:convertNumber type=... / ? Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Check for application specific resource bundle before the embedded one
I guess +1 The spec only truly requires this for messages that are created by the JSF implementation, but it's common practice to apply this to other messages. -- Adam On 3/13/07, Gabrielle Crawford [EMAIL PROTECTED] wrote: +1 This seems to match the spec, which defines the algorithm below, so we'd just use org.apache.myfaces.trinidad.resource.MessageBundle instead of javax.faces.Messages. The following algorithm must be used to create a FacesMessage instance given a message key. ■ Call getMessageBundle() on the Application instance for this web application, to determine if the application has defined a resource bundle name. If so, load that ResourceBundle and look for the message there. ■ If not there, look in the javax.faces.Messages resource bundle. thanks, Gab On 3/10/2007 11:04 AM, Simon Lessard wrote: Hello all, Currently, LocaleUtils loads resources from the embedded org.apache.myfaces.trinidad.resource.MessageBundle class before checking for the FacesMessage.FacesMessages bundle, leaving the application specific bundle completely out of the process, effectivelly preventing users from overloading the predefined Trinidad messages. Currently, the only workaround for this is the create a class named org.apache.myfaces.trinidad.resource.MessageBundle in your project and pray for the AS ClassLoader to load it before the jarred one. Therefore, I think we should add the application defined (in faces-config.xml) ResourceBundle as the top priority bundle for text resources. Any comments? Regards, ~ Simon
Re: Mark ui and uinode classes deprecated
+1! -- Adam On 3/10/07, Simon Lessard [EMAIL PROTECTED] wrote: Hello all, Since most renderers were already made Faces major, I think it would be a good time to make the packages ui and uinode deprecated. Such change should allow us to easily detect remaining dependencies to those two packages and thus remove them. This will also make it more obvious for Trinidad users that those package should no longer be used for new components. Is there any objection, comments? Regards, ~ Simon
Re: [vote] release of core (1.0.0-incubating)
In all honesty, I haven't had a chance to look at the bits... I'd want to vote +1, but that seems a bit against-the-spirit... -- Adam On 3/9/07, Bernd Bohmann [EMAIL PROTECTED] wrote: [ ] +1 (Binding) for PPMC members only [X] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Matt Cooper wrote: [ ] +1 (Binding) for PPMC members only [X] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. On 3/9/07, Bruno Aranda [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. On 09/03/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. -M
Re: [vote] release of core (1.0.0-incubating)
phew! :) -- Adam On 3/9/07, Mike Kienenberger [EMAIL PROTECTED] wrote: Hey Adam, It's open source. You're not obligated to be involved in everything and every decision :-) On 3/9/07, Adam Winer [EMAIL PROTECTED] wrote: In all honesty, I haven't had a chance to look at the bits... I'd want to vote +1, but that seems a bit against-the-spirit... -- Adam On 3/9/07, Bernd Bohmann [EMAIL PROTECTED] wrote: [ ] +1 (Binding) for PPMC members only [X] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Matt Cooper wrote: [ ] +1 (Binding) for PPMC members only [X] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. On 3/9/07, Bruno Aranda [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. On 09/03/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: [X] +1 (Binding) for PPMC members only [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. -M
Re: about maven-faces-plugin
On 3/8/07, Martin Marinschek [EMAIL PROTECTED] wrote:
I still wonder if the approach MyFaces originally had wasn't better
than the new approach of the generator in Trinidad.
Apart from the fact of course that generation should happen on every
run of the build - we kind of neglected that.
What you have with the Trinidad generator now is:
...Template.java:
...
void myMethod() {
setMyProperty(test); //won't compile, cause setMyProperty is autogenerated!
}
The generator suports a special syntax:
/**/public abstract setMyProperty(...)
for just this sort of thing.
with the MyFaces initial method, this was all in one file, with special markers:
Component.java
void myMethod(){
setMyProperty(test); //compiles, cause in the same file
}
/** auto generated begin - don't change this code **/
public void setProperty(String property) {...}
/** auto generated end - don't change this code **/
But that means that you've checked into source control
auto-generated code. Which is a BIG problem.
Auto-generated code should be generated at build
time, and never get checked in.
-- Adam
Re: tr:datetimeconverter and shortish style
The intent of the code is absolutely to use the two-digit year start to handle two-digits entries. If that isn't happening, it's a pretty bad bug. -- Adam On 3/8/07, Yee-wah Lee [EMAIL PROTECTED] wrote: Hi all, I see the following code in the (server-side) DateTimeConverter and think it may be problematic. 1) The default style for dates is set to shortish, which forces the year pattern to be at least 4 digits (http://incubator.apache.org/adffaces/trinidad-api/apidocs/org/apache/myfaces/trinidad/convert/DateTimeConverter.html) /New dateStyle |shortish| has been introduced. Shortish is identical to |short| but forces the year to be a full four digits. If dateStyle is not set, then |dateStyle| defaults to |shortish|. / 2) Accordingly, the converter sets the pattern on its DateFormat to use at least 4 digits, if 'y' appears at all. The method is _get4YearFormat() 3) Now, the Javadoc states this for SimpleDateFormat (http://java.sun.com/j2se/1.5.0/docs/api/java/text/SimpleDateFormat.html) /For parsing, if the number of pattern letters is more than 2, the year is interpreted literally, regardless of the number of digits. So using the pattern MM/dd/, 01/11/12 parses to Jan 11, 12 A.D. / So why I think this is a problem: * From the user's perspective, if they enters a date like '1/31/07', it becomes January 31st, 7 A.D rather than the (more likely intended) January 31st, 2007. * It also seems like the code intends otherwise, because it also calls DateFormat's set2DigitYearStart() which is intended for parsing 2 digit years. Does anyone have more background on this? I was able to reproduce the behavior using an inputText bound to a backing Date value, and a DateTimeConverter attached to it. Thanks, Yee-Wah
Re-branch JSF 1.2?
I'm thinking of re-branching JSF 1.2 from the current trunk. Does anyone have a reason to delay? -- Adam
Re: about maven-faces-plugin
In general, I think the approach used by the faces plugin
is a really good thing. You want as much autogenerated
as possible (this made upgrading to JSF 1.2 vastly easier
than without it). And the specific approach actually
allows for treating the template .java files as fully
compileable sources - you can add them to your IDE
and get full code insight, syntax checking, etc. Most
systems I've seen for templated code don't offer that;
the templated Java is pseudo-code that no IDE will
accept.
I agree with Bruno that the plugin could definitely
be improved... some injection might be good,
velocity templates for method generation would
probably be wy easier than all the Java code, etc.
-- Adam
On 3/7/07, Bruno Aranda [EMAIL PROTECTED] wrote:
IMO I prefer to use as much as I can the code autogenerated without
having to add new code to the methods (delegating all this to the code
generator). This eases the process of migrating code. Adding very
specific code to methods might break future migrations (e.g. migrating
tomahawk components to use trinidad state management), as the specific
code could no longer compile. Of course, this can be a minor thing so
I am open to this possibility of injecting code before/after the
method's logic, as aspects do. How would you do it, though?
And of course, there is a great space for improving in the plugin and
it would be wonderful at some point to have it based in velocity,
Cheers,
Bruno
On 07/03/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi all,
During myfaces 1.2 development I came across the maven-faces-plugin from
trinidad. AFAIK it uses some xml files which contains the model for
the generated components. This saves a lot of time to quickly get new
components into work. But there is room to improve it.
Currently customizing the generated component classes requires to
write a template file (like UIViewRootTemplate.java) which contains
custom code. I don't like this approach. Since there is no chance to
modify generated methods and to add custom code. That is even worse if
you only want to add something to save/restore state methods or to add
some parameter checking for setters. I've already seen that some dirty
hacks are implemented to make things work - at least for using it in myfaces.
IMO there is a way to solve some of the problems by still having
generated code. I'm thinking of an in place editing the generated
code inside special marks like this:
public void setXXX(String xxx)
{
/* start custom code */
// do something before the generated code
/* end custom code */
_XXX = xxx;
/* start custom code */
// do something after the generated code
/* end custom code */
}
WDYT?
--
Mathias
Re: Volunteers for the Incubator board report ?
I added some more material. -- Adam On 3/7/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: updated On 3/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: k On 3/6/07, Martin van den Bemt [EMAIL PROTECTED] wrote: I also (normally) tend to add something about what is planned / future expectations (like release of core, working on the graduation checklist, etc). Mvgr, Martin Matthias Wessendorf wrote: If sb. has more content for http://wiki.apache.org/incubator/March2007 please, post it here ! Thx, On 3/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: date is 12th, I'll create them later today. thx for the reminder. On 3/6/07, Martin van den Bemt [EMAIL PROTECTED] wrote: I am not volunteering, but it is board report time again... Mvgr, Martin -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: about maven-faces-plugin
On 3/7/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
what I didn't like this morning, for fixing a bug on MyFAces' JSF 1.2
UIViewRoot is,
that I need to put this statement:
/**///getPhaseListeners
to get a *ignored* getter for the phaseListeners property.
Well, you need this if you're going to try to compile
the template, and you need to refer to a method that will
be auto-generated from code that isn't auto-generated.
If you're not compiling the template, that's not necessary.
It's certainly not pretty - an annotation of some sort
would be way better - but it has the distinct advantage
of being a piece of logic that I could code in minutes.
(The principle of Good Enough applies. :) )
-- Adam
The rest is fine, at least the part I was dealing w/ in order to get
some stuff working in Trinidad
-M
On 3/7/07, Adam Winer [EMAIL PROTECTED] wrote:
In general, I think the approach used by the faces plugin
is a really good thing. You want as much autogenerated
as possible (this made upgrading to JSF 1.2 vastly easier
than without it). And the specific approach actually
allows for treating the template .java files as fully
compileable sources - you can add them to your IDE
and get full code insight, syntax checking, etc. Most
systems I've seen for templated code don't offer that;
the templated Java is pseudo-code that no IDE will
accept.
I agree with Bruno that the plugin could definitely
be improved... some injection might be good,
velocity templates for method generation would
probably be wy easier than all the Java code, etc.
-- Adam
On 3/7/07, Bruno Aranda [EMAIL PROTECTED] wrote:
IMO I prefer to use as much as I can the code autogenerated without
having to add new code to the methods (delegating all this to the code
generator). This eases the process of migrating code. Adding very
specific code to methods might break future migrations (e.g. migrating
tomahawk components to use trinidad state management), as the specific
code could no longer compile. Of course, this can be a minor thing so
I am open to this possibility of injecting code before/after the
method's logic, as aspects do. How would you do it, though?
And of course, there is a great space for improving in the plugin and
it would be wonderful at some point to have it based in velocity,
Cheers,
Bruno
On 07/03/07, Mathias Brökelmann [EMAIL PROTECTED] wrote:
Hi all,
During myfaces 1.2 development I came across the maven-faces-plugin from
trinidad. AFAIK it uses some xml files which contains the model for
the generated components. This saves a lot of time to quickly get new
components into work. But there is room to improve it.
Currently customizing the generated component classes requires to
write a template file (like UIViewRootTemplate.java) which contains
custom code. I don't like this approach. Since there is no chance to
modify generated methods and to add custom code. That is even worse if
you only want to add something to save/restore state methods or to add
some parameter checking for setters. I've already seen that some dirty
hacks are implemented to make things work - at least for using it in
myfaces.
IMO there is a way to solve some of the problems by still having
generated code. I'm thinking of an in place editing the generated
code inside special marks like this:
public void setXXX(String xxx)
{
/* start custom code */
// do something before the generated code
/* end custom code */
_XXX = xxx;
/* start custom code */
// do something after the generated code
/* end custom code */
}
WDYT?
--
Mathias
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: myfaces version
+1. -- Adam On 3/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: hello, ok if I change the myfaces version from 1.1.4 to 1.1.5 ? at least I'd like to continue preparing the core release, based on that. if you agree, I'll update! -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [JSF 1.2] UIXCOMMAND
Yep, but:
https://java.sun.com/javaee/5/docs/api/javax/faces/component/ActionSource.html
... marks setActionListener() as deprecated. Though, I'd
have no problems adding @Deprecated to our UIXCommand
methods too.
-- Adam
On 3/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
/**
* Sets a method reference to an action listener
*
* @param actionListener the new actionListener value
*/
final public void setActionListener(MethodBinding actionListener)
{
setProperty(ACTION_LISTENER_KEY, (actionListener));
}
that's in the UIXCommand.java of
trinidad-api\target\maven-faces-plugin\main\java\org\apache\myfaces\trinidad\component
-M
On 3/5/07, Adam Winer [EMAIL PROTECTED] wrote:
Yes. I'd have thought this would be marked deprecated
on ActionSource, though, which means we'd be inheriting
that deprecation?
-- Adam
On 3/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
should we set the setActionListener() to deprecated, like done in
UICOMMAND of plain JSF ?
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: GlobalConfiguratorImpl not called _releaseRequestContext
I'd check to make sure how many times GlobalConfiguratorImpl. beginRequest() and endRequest() are being called per request. It should be once, but maybe it's happening twice on your machine, in which case a couple of stack dumps would be a good clue. -- Adam On 3/5/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Here on my Jetty 6.x.y, the GlobalConfiguratorImpl doesn't call _releaseRequestContext(). I am running here a very small Trinidad app... and I see this WARNING: RequestContext had not been properly released on earlier request. Reason is: RequestType.getType(externalContext) != null == false Anyone knows more ? Thx, Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Client-side validation - enhance to match server-side
Trinidad already has essentially the same functionality - input components can be marked as autoSubmit, at which point tabbing out will automatically trigger a server-side submit, and error messages will be automatically inserted into tr:messages, if present. (There's an existing bug where the inline messages don't show up). -- Adam On 3/1/07, Peter Muir [EMAIL PROTECTED] wrote: On 28/02/07, Danny Robinson [EMAIL PROTECTED] wrote: Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. You should look at the way this is done in A4J - the server side validators are used: the onblur of the input causes it's value to be sent, and then rendering any error messages (in the normal places), again using ajax. Very neat IMO. Pete
Re: @author tags
We should be including the name of the patch author in every checkin message. I used to be in that habit, got out of it, and I'm trying to do a better job with it lately. -- Adam On 3/1/07, Simon Lessard [EMAIL PROTECTED] wrote: Not exactly, SVN show only the name of the commiter, not the actual developper. However it's true that with SVN log you can get the JIRA issue number and then see who made the patch. On 3/1/07, Mike Kienenberger [EMAIL PROTECTED] wrote: There's already a system in place that tracks the changes and who made them. It's called svn :-) It's going to be far more accurate and complete than a system you maintain manually :-) On 2/28/07, Simon Lessard [EMAIL PROTECTED] wrote: I'm +0 about it. I think it's nice to know who wrote a piece of code before you modify it, so you can ask a quick question to the author. The main example I can find in Trinidad is the use of Hashtable and Vector every now and then, was it because of the old 1.2 codebase or was synchronization required? A simple mail to the author would have answered that question. Then again, I can see Craig's point as well as ASF concerns. The best compromise I can find is maintaining a history of changes in the Javadoc with the author names, but I really don't think many of us (starting with me) will have the patience to keep such a thing up-to-date, hence the +0.
Re: using trinidad as non-default render-kit
Changing how we get the RenderKit would break a lot of code,
so I'd be a big -1 on that.
There's other parts of the ExtendedRenderKitService
contract, and, yes, they'll be hard to enforce in general.
Facelets could actually fix this quite elegantly by
getting the renderKitId correct in createView(), which
should theoretically be possible.
I think the thing to do for this issue is to let CoreRenderer
call encodeBegin() if the RenderingContext hasn't been
called, and allow ViewHandlerImpl to recompute the
ExtendedRenderKitService after renderView() (since the
renderKitId will be correct by then).
-- Adam
On 2/28/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
This is definitely harder than I expected. What about coupling the
RenderingContext with the used RenderingKit? And droping the
RenderingContext ThreadLocal based access in favour of
FacesContext.getCurrentInstance().getRenderKit().getRenderingContext().
The RenderKitBase could probably extended for handling the
RenderingContext?
I dont quite understand the reason behind the
ExtendedRenderKitService.encodeEnd() and
encodeFinally() contract. The only implementation I found was the
CoreRenderKit, and its doing nothing basically except for the
RenderingContext creation. Theres also no such contract in the jsf
RenderKit, so enforcement may turn out to become difficult.
On 2/24/07, Adam Winer [EMAIL PROTECTED] wrote:
Stefan,
Take a look at the code in ViewHandlerImpl - w/regard
to ExtendedRenderKitService and its encodeBegin() method. You
don't need to have any direct reference to CoreRenderingContext.
(Also, by only mucking with encodeBegin(), this'll fail
if the first Trinidad component is rendersChildren. In
your page, perhaps it's not, but most actually are.)
Once you use that, then you have to satisfy the contract
of ExtendedRenderKitService - calling
ExtendedRenderKitService.encodeEnd() and
encodeFinally(). That second half is the bigger trick,
especially because you really have to do
ExtendedRenderKitService.encodeBegin(), etc. exactly
once per page, not multiple times.
-- Adam
On 2/22/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Adam,
I think the CoreRenderer should take care of initializing the
RenderingContext. Facelets will be kind enough to set the rendering
kit in the FacesContext, as specified by the renderKitId attribute.
Since encodeBegin() will be called in the CoreRenderer impl., we
should know which RenderingContext we have to use, right?
Try the following hack. Its still not 100% working, but the page is
rendering.
CoreRenderer.java:
public final void encodeBegin(FacesContext context,
UIComponent component) throws IOException
{
if (!getRendersChildren())
{
RenderingContext arc = RenderingContext.getCurrentInstance();
if (arc == null) {
//throw new IllegalStateException(No RenderingContext);
try {
Class ctxClazz =
Class.forName(
org.apache.myfaces.trinidadinternal.renderkit.core.CoreRenderingContext);
arc = (RenderingContext) ctxClazz.newInstance();
} catch (Exception e) {
throw new IllegalStateException(e);
}
}
FacesBean bean = getFacesBean(component);
encodeBegin(context, arc, component, bean);
}
}
On 2/22/07, Adam Winer [EMAIL PROTECTED] wrote:
How are you thinking of tackling this one?
I didn't have any great ideas.
-- Adam
On 2/21/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Created the issue in jira.
https://issues.apache.org/jira/browse/ADFFACES-387
I'll hopefully be able to contribute a patch in the coming week,
if I
have the time for it.
On 2/20/07, Adam Winer [EMAIL PROTECTED] wrote:
Yep, re-reading it, that's exactly what you said. Sorry
for the misunderstanding. So this is a tougher nut
to crack. I can imagine some hacks to try to
instantiate the rendering context on the fly, but
nothing really obvious and bulletproof comes to mind.
I think we need a JIRA issue...
-- Adam
On 2/20/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
Hi Adam
I already have trinidad working with facelets. The problem is
it only
runs with trinidad as the *default rendering kit*. Defining
trinidad
as the rendering kit per page does *not* work. Please see my
first
mail for details.
On 2/19/07, Adam Winer [EMAIL PROTECTED] wrote:
Oh, I see. You're using Facelets. You need to configure
things
a bit differently than without Facelets. Check out:
http://wiki.apache.org/myfaces/Facelets_with_Trinidad
-- Adam
On 2/16/07, Stefan Podkowinski [EMAIL PROTECTED] wrote:
I just tried the other way around by setting trinidad as
default
render kit in faces-config.xml and f:view
Re: Client-side validation - enhance to match server-side
I'd be happy to see functionality like this too. The trickiest part is, I think, figuring out how to clear the messages. I agree with Matthias that we don't need GWT. We already have the client-side JS. It's just the code that decides to turn the messages into an alert that is the problem. -- Adam On 2/28/07, Martin Marinschek [EMAIL PROTECTED] wrote: I've been reiterating the necessity for this time and again ;) - I'd be pretty much for an addition like this. regards, Martin On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: I was thinking that instead of displaying alert, the messages would appear in the same place as they do in server-side. So keep the existing javascript validator/converter stuff but change where/how it is displayed. We'd probably have to render a hidden container for each field, which the javascript would populate and make visible. Taking this route over a dialog means we could also probably provide some kind of on-tab-out instant validation for more data-entry heavy applications. That said these approaches are not mutually exclusive. Danny On 2/28/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: are you talking about still using JS for the client side converter/validator stuff, but just don't use alert(), instead using a web2.0-ish dialog ? The validator/converter stuff isn't just an alert(). We have client side Converter (with getAsObject/String) and Validators (with validate) and FacesMessage etc. Here is more on that interesting topic: http://incubator.apache.org/adffaces/devguide/clientValidation.html -Matthias On 2/28/07, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Would there be support for an enhancement to the client-side validation so that it behaves in the same way as the server-side logic? Meaning, we'd get rid of the javascript alert dialog and instead dyanamically show/hide the error messages in the page. If so, I'll raise a JIRA issue and look into possible solutions. Tips suggestions welcome. Danny -- Chordiant Software Inc. www.chordiant.com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Chordiant Software Inc. www.chordiant.com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: @author tags
I agree as well. There's something a little nice about @author tags as a way of giving credit to the people who aren't the obvious people on a project. But they're rarely kept up to date, and the implication of ownership is not very OSS-friendly. -- Adam On 2/26/07, Craig McClanahan [EMAIL PROTECTED] wrote: On 2/26/07, Scott O'Bryan [EMAIL PROTECTED] wrote: -1 for removing them. I don't see this as an ownership issue. It's helpful to know who in the community might be able to answer questions on a particular piece of code. I know with the Portal work I did, it was very handy to know WHO had written a piece of code, especially since they may not me monitoring the lists. This argument does not scale in the long term. My own experience is a case in point -- my name is still splattered over lots of the Catalina sources inside Tomcat, even though: * I have not worked on them for four years (but I still get 20 personal emails for Tomcat help every week). * In many cases, the number of lines of code that were mine originally is less than half of the total -- so the tag is totally misleading. * The real people you want to talk to are the ones who have been making recent commits, not whoever wrote the code in the first place. I am strongly i+1 on removing @author tags, for the community related reasons that have been previously published. Craig McClanahan
Re: versioning
On 2/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I changed the trunk plugins to have 1.0.1-incubating-SNAPSHOT as its version. I changed the trunk core to have 1.0.1-incubating-SNAPSHOT as its version. I created also a branch for core to work on a release of 1.0.0-incubating, which will depend on the released 1.0.0-incubating Plugins (see my earlier mail from today). For now, I think the CORE trunk should depend on the *trunk* of the plugins. Another option would be to just depend on the released stuff of the plugins. I am fine with both. I think the CORE trunk should depend on released plugins, until there's a need to rev to snapshots. And, ideally, we'd rarely even do that. We'd put out new releases of the plugin if CORE needed bug fixes urgently. In practice, though, this may be very difficult since the two are somewhat coupled. -- Adam In case of we need a fix for the plugins we have two possible scenarios: CORE depends on a released version: when trying to release CORE and seeing an issue in the plugins, we need to release that particular plugin (or all at once), to have the trunk use the fixed patched plugins. CORE depends on SNAPSHOT A fix is quicker, since both artifacts are SNAPSHOTS. But at the end, to be able to release the CORE, we also need a release the plugins before that. One more, since we, the Apache MyFaces/Trinidad community is in charge of the PLUGINS and the CORE, there isn't that big issue in depending on a SNAPSHOT, since it is our code. What do you guys think? Thanks, Matthias
Re: [ANN] Release of Trinidad's Maven plugins (1.0.0-incubating)
Thanks for all your work getting this out, Matthias! -- Adam On 2/27/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, The Apache Trinidad community is pleased to announce its 1.0.0-incubation release of the Trinidad Maven2 plugins. These Maven2 plugins have been deployed to the Apache Incubator Maven2 repository ([1]). For more informations on the Apache Trinidad podling, please visit our homepage ([2]). For detailed information about what's in this release see our release notes ([3]). [1] http://people.apache.org/repo/m2-incubating-repository/ [2] http://incubator.apache.org/adffaces [3] http://svn.apache.org/viewvc/incubator/adffaces/tags/maven-plugin-parent-1.0.0-incubating/RELEASE_NOTES?revision=512245view=markuppathrev=512245 Incubation Apache Trinidad is an effort undergoing incubation at the Apache Software Foundation (ASF). Incubation is required of all newly accepted projects until a further review indicates that the infrastructure, communications, and decision making process have stabilized in a manner consistent with other successful ASF projects. While incubation status is not necessarily a reflection of the completeness or stability of the code, it does indicate that the project has yet to be fully endorsed by the ASF.
Re: using trinidad as non-default render-kit
How are you thinking of tackling this one? I didn't have any great ideas. -- Adam On 2/21/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: Created the issue in jira. https://issues.apache.org/jira/browse/ADFFACES-387 I'll hopefully be able to contribute a patch in the coming week, if I have the time for it. On 2/20/07, Adam Winer [EMAIL PROTECTED] wrote: Yep, re-reading it, that's exactly what you said. Sorry for the misunderstanding. So this is a tougher nut to crack. I can imagine some hacks to try to instantiate the rendering context on the fly, but nothing really obvious and bulletproof comes to mind. I think we need a JIRA issue... -- Adam On 2/20/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: Hi Adam I already have trinidad working with facelets. The problem is it only runs with trinidad as the *default rendering kit*. Defining trinidad as the rendering kit per page does *not* work. Please see my first mail for details. On 2/19/07, Adam Winer [EMAIL PROTECTED] wrote: Oh, I see. You're using Facelets. You need to configure things a bit differently than without Facelets. Check out: http://wiki.apache.org/myfaces/Facelets_with_Trinidad -- Adam On 2/16/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: I just tried the other way around by setting trinidad as default render kit in faces-config.xml and f:view .. renderKitId=HTML_BASIC. Afterwards the page renders fine but I'm getting an error on submit: javax.faces.application.ViewExpiredException: viewId:/jsfexamples/examples-simple-1.jsf - View /jsfexamples/examples-simple-1.jsf could not be restored. com.sun.faces.lifecycle.RestoreViewPhase.execute( RestoreViewPhase.java:180) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java :248) If I remove trinidad as default rendere kit, submit works too. Whats also a bit concerning here is that with trinidad as default render kit, the following hidden field is also generated every time for the form tag, not taking f:view renderKitId=.. into account: input type=hidden name=javax.faces.RenderKitId value=org.apache.myfaces.trinidad.core / On 2/16/07, Adam Winer [EMAIL PROTECTED] wrote: Stefan, We have a JSF 1.2 branch of Trinidad which is well tested, and contains (nearly) the latest code. http://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-070201/ The only bad news is that you currently have to build it yourself - we don't have an automated build going for this branch. (FYI, we rebranch every once in awhile, and the URL changes when we do.) -- Adam On 2/15/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: Hello Currently it does not seem to be possible to use trinidad with jsf1.2 ri and facelets and not having trinidad declared as default rendering kit. Removing default-render-kit-idorg.apache.myfaces.trinidad.core /default-render-kit-id from faces-config.xml and adding the render kit declaration to the view root f:view ... renderKitId=org.apache.myfaces.trinidad.core will break the view handling process with the following error: java.lang.IllegalStateException: No RenderingContext at org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin (CoreRenderer.java:159) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin( UIXComponentBase.java:668) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive( UIXComponentBase.java:1209) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll( UIXComponentBase.java:721) at javax.faces.component.UIComponent.encodeAll( UIComponent.java:890) at com.sun.facelets.FaceletViewHandler.renderView( FaceletViewHandler.java:571) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView (ViewHandlerImpl.java:182) at com.sun.faces.lifecycle.RenderResponsePhase.execute( RenderResponsePhase.java:106) After doing some debuging, I came to the conclusion that this must be due to the trinidad ViewHandlerImpl.renderView() method implementation. The problem is the way the ViewHandlerImpl wraps the delegate, but needs to setup the RenderingContext before the delegate is executed. Creating the RenderingContext is currently done by CoreRenderKit.encodeBegin(). But this won't never happen in this case, because facelets did not parse the page including the f:view renderKitId.. element yet, so we don't know which render kit to use before calling the facelets delegate! So here's whats
Re: using trinidad as non-default render-kit
Yep, re-reading it, that's exactly what you said. Sorry for the misunderstanding. So this is a tougher nut to crack. I can imagine some hacks to try to instantiate the rendering context on the fly, but nothing really obvious and bulletproof comes to mind. I think we need a JIRA issue... -- Adam On 2/20/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: Hi Adam I already have trinidad working with facelets. The problem is it only runs with trinidad as the *default rendering kit*. Defining trinidad as the rendering kit per page does *not* work. Please see my first mail for details. On 2/19/07, Adam Winer [EMAIL PROTECTED] wrote: Oh, I see. You're using Facelets. You need to configure things a bit differently than without Facelets. Check out: http://wiki.apache.org/myfaces/Facelets_with_Trinidad -- Adam On 2/16/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: I just tried the other way around by setting trinidad as default render kit in faces-config.xml and f:view .. renderKitId=HTML_BASIC. Afterwards the page renders fine but I'm getting an error on submit: javax.faces.application.ViewExpiredException: viewId:/jsfexamples/examples-simple-1.jsf - View /jsfexamples/examples-simple-1.jsf could not be restored. com.sun.faces.lifecycle.RestoreViewPhase.execute( RestoreViewPhase.java:180) com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java :248) If I remove trinidad as default rendere kit, submit works too. Whats also a bit concerning here is that with trinidad as default render kit, the following hidden field is also generated every time for the form tag, not taking f:view renderKitId=.. into account: input type=hidden name=javax.faces.RenderKitId value=org.apache.myfaces.trinidad.core / On 2/16/07, Adam Winer [EMAIL PROTECTED] wrote: Stefan, We have a JSF 1.2 branch of Trinidad which is well tested, and contains (nearly) the latest code. http://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-070201/ The only bad news is that you currently have to build it yourself - we don't have an automated build going for this branch. (FYI, we rebranch every once in awhile, and the URL changes when we do.) -- Adam On 2/15/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: Hello Currently it does not seem to be possible to use trinidad with jsf1.2 ri and facelets and not having trinidad declared as default rendering kit. Removing default-render-kit-idorg.apache.myfaces.trinidad.core /default-render-kit-id from faces-config.xml and adding the render kit declaration to the view root f:view ... renderKitId=org.apache.myfaces.trinidad.core will break the view handling process with the following error: java.lang.IllegalStateException: No RenderingContext at org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin (CoreRenderer.java:159) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin( UIXComponentBase.java:668) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive( UIXComponentBase.java:1209) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll( UIXComponentBase.java:721) at javax.faces.component.UIComponent.encodeAll( UIComponent.java:890) at com.sun.facelets.FaceletViewHandler.renderView( FaceletViewHandler.java:571) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView (ViewHandlerImpl.java:182) at com.sun.faces.lifecycle.RenderResponsePhase.execute( RenderResponsePhase.java:106) After doing some debuging, I came to the conclusion that this must be due to the trinidad ViewHandlerImpl.renderView() method implementation. The problem is the way the ViewHandlerImpl wraps the delegate, but needs to setup the RenderingContext before the delegate is executed. Creating the RenderingContext is currently done by CoreRenderKit.encodeBegin(). But this won't never happen in this case, because facelets did not parse the page including the f:view renderKitId.. element yet, so we don't know which render kit to use before calling the facelets delegate! So here's whats happening in ViewHandlerImpl: 160: ExtendedRenderKitService cannot be found because trinidad is not the default anymore 172: CoreRenderKit will not be called to setup RenderingContext (thread local) 182: delegation to FaceletViewHandler afterwards org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin( CoreRenderer.java:159) fails on non initialized thread local. What do you think? Is there a chance to reimplement ViewHandlerImpl.renderView() so this problem could be resolved? Any possible side effects? Thanks, Stefan
Re: Split up the CSS across multiple files
On 2/14/07, Chris Eidhof [EMAIL PROTECTED] wrote: Hey everyone, I really don't like very long files, and especially the long css-files. So I was wondering: why don't we split up the css-file into multiple files: one components-shared.css, and one file for each component. I think that this will create more overview, and it separates things a bit more. Also, I'm working on a project with a really large skin, so there's a lot of other issues with editing such a file (my scrollbar moves a lot of lines per pixel, I can't really browse anymore but have to search a lot, etc.). Mostly minor things, but it's still annoying. Furthermore, the project I'm working on has multiple skin-files, and I think it would be much more convenient to have my rules grouped by component instead of per skin. This is a related, but different feature. So the features I'm proposing: * Support @import for including other stylesheets +1. * Separate large stylesheets into component-specific stylesheets No reason not to, once we have @import. * Be able to define rules for multiple skins in one file (I guess we need to extend the syntax for that). Eh, -1 I think... this seems contrary to the idea of having smaller files. I'm not sure the benefit is worth the extra syntax and code. -- Adam
Re: versioning
On 2/15/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Ok, ... so my plugins branch currently uses 1.0.1-incubating-SNAPSHOT I'll merge that to trunk AFTER we actually released the plugins. I think that technically this should happen now. 1.0.0 has already branched, right? If someone checked in code to the plugins, then we'd have some JARs floating around that claim to be 1.0.0-SNAPSHOT, but contain bits that will never appear in a 1.0.0 release. When merging to trunk the new version, I am also adding the released 1.0.0-incubating as the dependency. And change the CORE version to 1.0.0-incubating-SNAPSHOT. Are you saying that the trunk of trinidad will point at the released version of the plugins, after the release? If so, +1. -- Adam After that all I'll create a branch of CORE to prepare the release as well Sounds ok? -M On 2/13/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I go with 1.0.0-incubating-SNAPSHOT thanks, Matthias On 2/4/07, Martin Marinschek [EMAIL PROTECTED] wrote: Sure, d'accord - just like the Tomcat folks do it, it doesn't make sense to keep the product versions fully at the spec or API versions. We should do the same for MyFaces and Tomahawk, by the way. regards, Martin On 2/4/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: resent, because went to PMC list. On 2/3/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: hi guys, currently our stuff has no real version number; only M1, which is almost nothing. I think we should name the current Trinidad stuff 1.0.0 and put the m1 (or incubator or incubating) to it, because of being incubator (for plugins and core). So something like: versionincubator-m1-SNAPSHOT/version would be: version1.0.0-incubating-SNAPSHOT/version The incubating I saw, when looking at OpenJPA. (of course w/o SNAPSHOT, after we do a release) For the JSF 1.2 branch I suggest to use the version 2.0 I think it doesn't make sense to follow the JSF version system in the version system of us. So, according to some blog entries, the next version for JSF (targeted for Java EE 6), will be called JSF 6. That would mean, if we stay tightly with their system we'd have a release or Trinidad 1.0 (mustn't it be 1.1 ??) Trinidad 1.2 Trinidad 6 which is really confusing (to me). So, to sum it up: -the current Trinidad stuff (based on JSF 1.1) will be 1.0.0 -the *future* stuff (based on JSF 1.2) will be the 2.0.0 stuff -In case of JSF 6, we simply have a 3.0.0. -using $version-incubating instead of $version-m1 Any comments ? -Matthias -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: using trinidad as non-default render-kit
Stefan, We have a JSF 1.2 branch of Trinidad which is well tested, and contains (nearly) the latest code. http://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-070201/ The only bad news is that you currently have to build it yourself - we don't have an automated build going for this branch. (FYI, we rebranch every once in awhile, and the URL changes when we do.) -- Adam On 2/15/07, Stefan Podkowinski [EMAIL PROTECTED] wrote: Hello Currently it does not seem to be possible to use trinidad with jsf1.2 ri and facelets and not having trinidad declared as default rendering kit. Removing default-render-kit-idorg.apache.myfaces.trinidad.core/default-render-kit-id from faces-config.xml and adding the render kit declaration to the view root f:view ... renderKitId=org.apache.myfaces.trinidad.core will break the view handling process with the following error: java.lang.IllegalStateException: No RenderingContext at org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:159) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeBegin(UIXComponentBase.java:668) at org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1209) at org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:721) at javax.faces.component.UIComponent.encodeAll(UIComponent.java:890) at com.sun.facelets.FaceletViewHandler.renderView(FaceletViewHandler.java:571) at org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:182) at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106) After doing some debuging, I came to the conclusion that this must be due to the trinidad ViewHandlerImpl.renderView() method implementation. The problem is the way the ViewHandlerImpl wraps the delegate, but needs to setup the RenderingContext before the delegate is executed. Creating the RenderingContext is currently done by CoreRenderKit.encodeBegin(). But this won't never happen in this case, because facelets did not parse the page including the f:view renderKitId.. element yet, so we don't know which render kit to use before calling the facelets delegate! So here's whats happening in ViewHandlerImpl: 160: ExtendedRenderKitService cannot be found because trinidad is not the default anymore 172: CoreRenderKit will not be called to setup RenderingContext (thread local) 182: delegation to FaceletViewHandler afterwards org.apache.myfaces.trinidad.render.CoreRenderer.encodeBegin(CoreRenderer.java:159) fails on non initialized thread local. What do you think? Is there a chance to reimplement ViewHandlerImpl.renderView() so this problem could be resolved? Any possible side effects? Thanks, Stefan
Re: [Skinning] FileSystemStyleCache code - ok to delete?
Die die die. :)
Unused code should almost always go. It can always
be revived from source control, and if it's unused, the
odds that it works steadily decreases as time goes on.
-- Adam
On 2/12/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
I'm trying to figure out what's going on in FileSystemStyleCache
regarding the caching code.
I noticed that this code is not called by anyone. Does anyone object to
my deleting it? Or is there
some use for it so I should keep it around.
/**
* Returns a shared ImageProvider instance for the specified
* XSS document and target cache directory.
*
* @param source The path of the source XSS document. The
* specified file must be a valid XSS document. If the specified
* file does not exists, an IllegalArgumentException is thrown.
* @param target The path of the target directory. Generated
* CSS files are stored in this directory. If the directory
* does not exist and can not be created, an IllegalArgumentException
* is thrown.
*/
public static StyleProvider getSharedCache(
String source,
String target
)
{
// Make sure we have some source/target.
if (source == null)
throw new IllegalArgumentException(No source specified.);
if (target == null)
throw new IllegalArgumentException(No target specified.);
// First, get the key to use to look up the cache
String key = _getSharedCacheKey(source, target);
// See if we've got a shared cache
StyleProvider cache = _sSharedCaches.get(key);
// If we didn't find a shared cache, create a new cache
// and cache it in the shared cache cache. :-)
if (cache == null)
{
// Create the new cache
cache = new FileSystemStyleCache(source, target);
// Before we save the new cache, make sure another thread hasn't
// already cached a different instance. Synchronize to lock up
// _sSharedCaches.
synchronized (_sSharedCaches)
{
StyleProvider tmp = _sSharedCaches.get(key);
if (tmp != null)
{
// Stick with tmp
cache = tmp;
}
else
{
_sSharedCaches.put(key, cache);
}
}
}
return cache;
}
Re: svn commit: r505339 - in /incubator/adffaces/trunk/trinidad: trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upl
This checkin doesn't seem right.
The ClassLoaderUtils changes are unnecessary, as
ClassLoaderUtils already checks the context ClassLoader
first; there's no reason for the change to this code.
And all the changes to the other classes are wrong: they
should just be calling ClassLoaderUtils.loadClass(String),
which is the utility function we have for this purpose.
So, for example, instead of:
laf = Class.forName(lafString);
becoming:
laf = Class.forName(lafString, true,
Thread.currentThread().getContextClassLoader());
it should be:
laf = ClassLoaderUtils.loadClass(lafString);
-- Adam
On 2/9/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: matzew
Date: Fri Feb 9 08:02:27 2007
New Revision: 505339
URL: http://svn.apache.org/viewvc?view=revrev=505339
Log:
ADFFACES-378 thanks to Bud Osterberg for the patch
Modified:
incubator/adffaces/trunk/trinidad/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ClassLoaderUtils.java
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFileProcessorImpl.java
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/xml/parse/ColorizedIconParser.java
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/util/ExternalContextUtils.java
Modified:
incubator/adffaces/trunk/trinidad/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ClassLoaderUtils.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ClassLoaderUtils.java?view=diffrev=505339r1=505338r2=505339
==
---
incubator/adffaces/trunk/trinidad/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ClassLoaderUtils.java
(original)
+++
incubator/adffaces/trunk/trinidad/trinidad-api/src/main/java/org/apache/myfaces/trinidad/util/ClassLoaderUtils.java
Fri Feb 9 08:02:27 2007
@@ -129,7 +129,8 @@
if (callerClassLoader != null)
clazz = callerClassLoader.loadClass(name);
else
-clazz = Class.forName(name);
+clazz = Class.forName(name, true,
+ Thread.currentThread().getContextClassLoader());
}
return clazz;
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFileProcessorImpl.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFileProcessorImpl.java?view=diffrev=505339r1=505338r2=505339
==
---
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFileProcessorImpl.java
(original)
+++
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/UploadedFileProcessorImpl.java
Fri Feb 9 08:02:27 2007
@@ -241,8 +241,9 @@
Class request;
try
{
- context = Class.forName(javax.portlet.PortletContext);
- request = Class.forName(javax.portlet.PortletRequest);
+ ClassLoader loader = Thread.currentThread().getContextClassLoader();
+ context = Class.forName(javax.portlet.PortletContext, true, loader);
+ request = Class.forName(javax.portlet.PortletRequest, true, loader);
}
catch (final ClassNotFoundException e)
{
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/xml/parse/ColorizedIconParser.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/xml/parse/ColorizedIconParser.java?view=diffrev=505339r1=505338r2=505339
==
---
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/xml/parse/ColorizedIconParser.java
(original)
+++
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/image/xml/parse/ColorizedIconParser.java
Fri Feb 9 08:02:27 2007
@@ -73,7 +73,8 @@
Class? laf = null;
try
{
- laf = Class.forName(lafString);
+ laf = Class.forName(lafString, true,
+ Thread.currentThread().getContextClassLoader());
}
catch ( ClassNotFoundException e )
{
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/util/ExternalContextUtils.java
URL:
Re: About the HTML Validator (W3C)
IIRC, there's still some errors that we generate. I'd like to really reduce these as much as possible, though. -- Adam On 2/6/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: I don't think so. -M On 2/7/07, Eric Marcoux [EMAIL PROTECTED] wrote: Hello, Does the Apache Trinidad components fully supports HTML 4.01 Strict or Transitional ? I am asking this question because ADF Faces does not fully supports both of these - when we run the HTML Validator against a web page that has been generated by ADF Faces, we get some errors. Is this fixed in Trinidad ? Thanks. ___ Eric Marcoux... Senior Consultant Oracle Fusion Middleware Regional Director Fujitsu Consulting (www.dmrconseil.ca) Weblog : http://emarcoux.blogspot.com Quebec JUG member (www.javaquebec.org) Sun Certified Programmer for Java 2 Platform Sun Certified Web Component Developer Sun Certified Business Component Developer -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: RE : About the HTML Validator (W3C)
We'd be happy to look at patches that improve our compatibility. -- Adam On 2/7/07, Eric Marcoux [EMAIL PROTECTED] wrote: Is there any plan to support HTML 4.01 Strict or Transitional in Trinidad or in the next version of ADF Faces RIA ? Thanks. ___ Eric Marcoux... JEE Technical Architect Oracle Fusion Middleware Regional Director Fujitsu Consulting (www.dmrconseil.ca) https://secure.dmr.com/exchweb/bin/redir.asp?URL=http://www.dmrconseil.ca) Weblog : http://emarcoux.blogspot.com Quebec JUG member (www.javaquebec.org) https://secure.dmr.com/exchweb/bin/redir.asp?URL=http://www.javaquebec.org) Sun Certified Programmer for Java 2 Platform Sun Certified Web Component Developer Sun Certified Business Component Developer De: [EMAIL PROTECTED] de la part de Matthias Wessendorf Date: mer. 2007-02-07 01:17 À: adffaces-dev@incubator.apache.org Objet : Re: About the HTML Validator (W3C) I don't think so. -M On 2/7/07, Eric Marcoux [EMAIL PROTECTED] wrote: Hello, Does the Apache Trinidad components fully supports HTML 4.01 Strict or Transitional ? I am asking this question because ADF Faces does not fully supports both of these - when we run the HTML Validator against a web page that has been generated by ADF Faces, we get some errors. Is this fixed in Trinidad ? Thanks. ___ Eric Marcoux... Senior Consultant Oracle Fusion Middleware Regional Director Fujitsu Consulting (www.dmrconseil.ca) Weblog : http://emarcoux.blogspot.com http://emarcoux.blogspot.com/ Quebec JUG member (www.javaquebec.org) Sun Certified Programmer for Java 2 Platform Sun Certified Web Component Developer Sun Certified Business Component Developer -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: Early Prototype - Dialog using DHTML / iFrame
Committed this patch - thanks! -- Adam On 2/6/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, just uploaded an updated patch. Dialogs will now appear at a fixed size if specified, or will resize to that of the first dialog page and remain that size for all other pages. Started work on also removing frame redirect from date picker also. Danny. On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/3/07, Danny Robinson [EMAIL PROTECTED] wrote: uploaded patch to jira - including extra bits for setting the dialog title using BodyRenderer. Nice! A few quick questions also: Could we add the popup config entry to the trinidad config file rather than web.xml and allow it to use a value binding - this way we can test both from the same test/demo app? We've generally stuck to using trinidad-config basically for things that are on the RequestContext, and I don't think this is going to end up there. For the purposes of this branch, it'd be OK if the function that tested if popups were supported had something really goofy like: facesContext.getViewRoot().getViewId().contains(Popup) ... which'd be useful enough for testing, which is what this branch is for. Quick questions: Should we use the height/width properties as the master setting for the dialog size, and only resize to content if they were not set? I guess we wouldn't want to auto-resize to content in every situation, or would we want to always initially set it. Perhaps you use height/width as a minimum setting, and grow if they're not set. Or, height/width are an absolute rule. If we use the BodyRenderer approach to also set the dialog size, how do we ensure it doesn't keep resizing if the dialog runs to many pages? You could just stash a JS flag on the popup object; once resized, flip the flag and stop resizing. Also title will change as you move from page to page in dialog - I guess this is appropriate through. Yes, that's what you want. We have a few more options for closing dialogs also as the javascript component could even close modals if you clicked-off the dialog - in some instances this could be useful. Indeed, could be very useful! -- Adam On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, Could you attach that patch to http://issues.apache.org/jira/browse/ADFFACES-307? This is the more official way of doing things. -- Adam On 2/2/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/2/07, Danny Robinson [EMAIL PROTECTED] wrote: Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-). I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME Great! DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup ().setTitle( document.title);) which works for me. Thoughts? I was thinking we could rely on BodyRenderer; if we detect when we're inside of a dialog (perhaps by looking at pageFlowScope), and when we know that dialogs are configured to use popups, fire Javascript in the body's onload. If they don't want to use our body renderer, then they don't get this fun. BTW, always be very careful when getting a property off of parent... Wrap it in try/catch, because if the parent is in a different URL domain, you can get a security exception. - Implement sizing correctly Same as for title - we need to know when the iframe has finished loading. Interestingly I can't seem to get the trinidad-demo stuff to run as it has errors complaining about a null process scope. Anyway - it works in my own little web app using the add number demo and date picker. Hrm, when I get a chance to merge it in, I'll have a look. -- Adam Danny On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, I grabbed the patch, made a branch, and applied it. I fixed up some things: - Moved (almost) all of the popup dialog and panel popup JS code into TrPanelPopup and TrPopupDialog wrapper objects - Fix coding convention problems: no tabs allowed
Re: Early Prototype - Dialog using DHTML / iFrame
FWIW, a couple things I've noticed: - On Safari, the popups have no border or background; in the launchDialog.jspx demo, when you have two popups up together, the title for one popup actually overlaps the next (are they both being placed at the same z-order?) - The sizing algorithm doesn't seem to work that well - everything is a bit too small (Safari + Firefox). -- Adam On 2/6/07, Adam Winer [EMAIL PROTECTED] wrote: Committed this patch - thanks! -- Adam On 2/6/07, Danny Robinson [EMAIL PROTECTED] wrote: OK, just uploaded an updated patch. Dialogs will now appear at a fixed size if specified, or will resize to that of the first dialog page and remain that size for all other pages. Started work on also removing frame redirect from date picker also. Danny. On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/3/07, Danny Robinson [EMAIL PROTECTED] wrote: uploaded patch to jira - including extra bits for setting the dialog title using BodyRenderer. Nice! A few quick questions also: Could we add the popup config entry to the trinidad config file rather than web.xml and allow it to use a value binding - this way we can test both from the same test/demo app? We've generally stuck to using trinidad-config basically for things that are on the RequestContext, and I don't think this is going to end up there. For the purposes of this branch, it'd be OK if the function that tested if popups were supported had something really goofy like: facesContext.getViewRoot().getViewId().contains(Popup) ... which'd be useful enough for testing, which is what this branch is for. Quick questions: Should we use the height/width properties as the master setting for the dialog size, and only resize to content if they were not set? I guess we wouldn't want to auto-resize to content in every situation, or would we want to always initially set it. Perhaps you use height/width as a minimum setting, and grow if they're not set. Or, height/width are an absolute rule. If we use the BodyRenderer approach to also set the dialog size, how do we ensure it doesn't keep resizing if the dialog runs to many pages? You could just stash a JS flag on the popup object; once resized, flip the flag and stop resizing. Also title will change as you move from page to page in dialog - I guess this is appropriate through. Yes, that's what you want. We have a few more options for closing dialogs also as the javascript component could even close modals if you clicked-off the dialog - in some instances this could be useful. Indeed, could be very useful! -- Adam On 2/3/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, Could you attach that patch to http://issues.apache.org/jira/browse/ADFFACES-307? This is the more official way of doing things. -- Adam On 2/2/07, Adam Winer [EMAIL PROTECTED] wrote: On 2/2/07, Danny Robinson [EMAIL PROTECTED] wrote: Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-). I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME Great! DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup ().setTitle( document.title);) which works for me. Thoughts? I was thinking we could rely on BodyRenderer; if we detect when we're inside of a dialog (perhaps by looking at pageFlowScope), and when we know that dialogs are configured to use popups, fire Javascript in the body's onload. If they don't want to use our body renderer, then they don't get this fun. BTW, always be very careful when getting a property off of parent... Wrap it in try/catch, because if the parent is in a different URL domain, you can get a security exception. - Implement sizing correctly Same as for title - we need to know when the iframe has finished loading. Interestingly I can't seem to get the trinidad-demo stuff to run as it has errors complaining about a null process scope
Re: [continuum] BUILD FAILURE: Apache Trinidad Impl
Does anyone understand this build failure? It's looking as
though the Trinidad Impl build is not finding the latest
Trinidad API. A clean rebuild on my local machine completes
successfully.
-- Adam
On 2/5/07, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Online report :
http://myfaces.zones.apache.org:8080/continuum/servlet/continuum/target/ProjectBuild.vm/view/ProjectBuild/id/149/buildId/8508
Build statistics:
State: Failed
Previous State: Ok
Started at: Mon, 5 Feb 2007 09:08:05 +
Finished at: Mon, 5 Feb 2007 09:10:32 +
Total time: 2m 27s
Build Trigger: Schedule
Exit code: 1
Building machine hostname: myfaces.zones.apache.org
Operating system : SunOS(unknown)
Java version : 1.5.0_10(Sun Microsystems Inc.)
Changes
matzew using multiple args in TrMessageFactory.createMessage
/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/Locale.js
matzew ensure that no 1970 date (meaning null as date
value) will be used.
/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/javascript/META-INF/adf/jsLibs/CoreFormat.js
Output:
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'source'.
[INFO]
[INFO] Building Apache Trinidad Impl
[INFO]task-segment: [clean, install, source:jar, deploy]
[INFO]
[INFO] snapshot
org.apache.myfaces.trinidadbuild:maven-faces-plugin:incubator-m1-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot
org.apache.myfaces.trinidadbuild:maven-i18n-plugin:incubator-m1-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot
org.apache.myfaces.trinidadbuild:maven-javascript-plugin:incubator-m1-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot
org.apache.myfaces.trinidadbuild:maven-xrts-plugin:incubator-m1-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] [clean:clean]
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/target
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/target/classes
[INFO] Deleting directory
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/target/test-classes
[INFO] snapshot org.apache.myfaces.trinidad:trinidad-api:incubator-m1-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot
org.apache.myfaces.trinidad:trinidad-build:incubator-m1-SNAPSHOT: checking for
updates from apache.snapshots
[INFO] [faces:generate-jsp-taglibs {execution: default}]
[INFO] Generated 141 JSP tag(s)
[INFO] [faces:generate-facelets-taglibs {execution: default}]
[INFO] Generated META-INF/tr.taglib.xml
[INFO] Generated META-INF/trh.taglib.xml
[INFO] [i18n:generate-locale-elements {execution: default}]
[INFO] Generating LocaleElements
[INFO] [i18n:generate-javascript-locales {execution: default}]
[INFO] Generating Javascript Locales
[INFO] [javascript:reduce-javascript {execution: default}]
[INFO] [xrts:generate-sources {execution: default}]
[INFO] Generating 32 XRTS bundles to
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/target/maven-xrts-plugin/main/java
[INFO] [faces:generate-faces-config {execution: default}]
[INFO] Generated META-INF/faces-config.xml
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:compile]
Compiling 1128 source files to
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/target/classes
[INFO]
[ERROR] BUILD FAILURE
[INFO]
[INFO] Compilation failure
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/ServletUploadedExternalContext.java:[28,43]
cannot find symbol
symbol : class ExternalContextDecorator
location: package org.apache.myfaces.trinidad.context
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/src/main/java/org/apache/myfaces/trinidadinternal/config/upload/ServletUploadedExternalContext.java:[39,45]
cannot find symbol
symbol: class ExternalContextDecorator
class ServletUploadedExternalContext extends ExternalContextDecorator
/local/continuum-1.0.3-SNAPSHOT/apps/continuum/working-directory/149/src/main/java/org/apache/myfaces/trinidadinternal/config/GlobalConfiguratorImpl.java:[28,42]
cannot find symbol
symbol : class Configurator
location: package org.apache.myfaces.trinidad.config
Re: Early Prototype - Dialog using DHTML / iFrame
On 2/2/07, Danny Robinson [EMAIL PROTECTED] wrote: Adam, I've posted a new patch file to thefoxberry.com if you want to take a look. It's based on your sandbox so it should apply cleanly with less for you to do this time ;-). I fixed a few of the todo's. - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME Great! DONE - small changes to DialogRequest and .CoreRenderKit - Added javascript code to only register events when popup shown DONE - Populate title of the popup based on the title of the dialog's content I've added this to the DialogPopup.js, but because we've removed the frameset from the popup, there doesn't seem a clean and safe way to get an onload event from the iframe so we know to go grab the title. The only way I see it will work is if something is added into the onload of the actual dialog page (e.g. parent.TrPanelPopup.getCurrentPanelPopup().setTitle( document.title);) which works for me. Thoughts? I was thinking we could rely on BodyRenderer; if we detect when we're inside of a dialog (perhaps by looking at pageFlowScope), and when we know that dialogs are configured to use popups, fire Javascript in the body's onload. If they don't want to use our body renderer, then they don't get this fun. BTW, always be very careful when getting a property off of parent... Wrap it in try/catch, because if the parent is in a different URL domain, you can get a security exception. - Implement sizing correctly Same as for title - we need to know when the iframe has finished loading. Interestingly I can't seem to get the trinidad-demo stuff to run as it has errors complaining about a null process scope. Anyway - it works in my own little web app using the add number demo and date picker. Hrm, when I get a chance to merge it in, I'll have a look. -- Adam Danny On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote: Danny, I grabbed the patch, made a branch, and applied it. I fixed up some things: - Moved (almost) all of the popup dialog and panel popup JS code into TrPanelPopup and TrPopupDialog wrapper objects - Fix coding convention problems: no tabs allowed, braces on new lines - Instead of removing the code that launched new windows for dialogs, hide it behind a web.xml context init parameter (currently defaulting to the old style) - Use resource bundle for translatable contents - Load JS automatically There's plenty to do still, most importantly: - Implement sizing correctly - Populate title of the popup based on the title of the dialog's content - Most importantly, for popup-based dialogs, do not use a FRAMESET inside of the IFRAME; just use the IFRAME But, that said: cool stuff! I think before we could look at merging anything into trunk, we'd need an Apache licensing agreement signed off on (because it's a non-trivial chunk of code...) -- Adam On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote: Patch file available here: http://thefoxberry.com/ Only note, is that this also contains the panelPopup component, and that you'll need to include the two .js files into the servlet that merges the common javascript. If I get chance later, I'll do this and repost the patch. Should work fine in Firefox or IE, others are untested. Danny On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote: I'll post up a .patch file later today. I used custom .js for the dialog, as I wasn't sure how we'd go about integrating a 3rd party lib, and the few I looked at didn't quite fit right, or had license issues. Besides, it was good practice. However, if we have a library that we're trying to integrate with on a larger scale, then I think it makes sense. D. On 1/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: HEy Danny, two things; 1) the image looks great. 2) do you use one of these days upcoming ajax-ish JavaScript libs? (or custom JS?) Another one, will you also provide the source in somewhat format? That would allow us to start with a sandbox .. Thanks, Matthias On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote: Hey, In a timely fashion, I've just seen Adams comments about wanting to switch to a DHTML/iFrame solution for dialog windows. I've pulled together a prototype set of changes that switches the default implementation of dialog windows, to use a floating popup iframe. It seems to work well and both the date picker dialog and the number picker demo work without any alteration. It is implemented as a javascript component that inherits from the basic panelPopup component I posted a while back. The prototype renders an iframe that blocks access to the parent window until the dialog returns. I say prototype, because I need some feedback on what is/isn't
Re: Oracle Skin Release
Thanks, I've created ADFFACES-371 to track getting rid of the old images. -- Adam On 2/2/07, Mark Robinson [EMAIL PROTECTED] wrote: Adam, I've got all the images I need packaged up in my JAR file. So you can remove the images from Trinidad. I can change the name fairly easily. I think RedwoodShores might be the best name ;) Mark Adam Winer wrote: Mark, FWIW, we probably should have deleted those images from Trinidad. Not because of licensing or anything - their license is fully transferred to Apache! - but because they're unused inside of Trinidad. I'd like to be able to delete them from Trinidad, and have them packaged with the skin that uses them. So, if there's any way you could incorporate the images you use into your skin's JAR, that would be great. Also, I'd recommend that you choose some new name for the skin, just to avoid any questions of ownership/copyright, etc., down the road. Cheers, Adam On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Matt, I've been working on a skin which looks like the old Oracle skin from ADF. There's been some moderate interest in it on the user mailing list. It is based upon images/CSS from inside Trinidad. What this means is that it's licensed under the Apache license. So it can be freely used inside Trinidad. I've packaged into a separate deployable jar for one reason. 1) It makes distributing/managing it so very easy Drop it into your WEB-INF/lib and change your skin to oracle and off you go. Otherwise, I'm completely infavour of re-integrating it back into mainline Trinidad. Anyways, you can download it at http://www.engr.uvic.ca/~mrobinso/OracleSkin.jar Mark Matthias Wessendorf wrote: what does that mean ? finished up the packing for thje Oracle Skin ? Is it like taking the ADF Faces Skin and bundling it separate? If yes, I am pretty much sure that we cannot have it here in Trinidad, since that code belongs Oracle. Oracle donated *parts* of ADF Faces to the ASF, what is now called Trinidad. If the code is something you/your company wrote on your own which is similar to the *Oracle Skin*, I am fine with that. I'd suggest uploading it to a private homepage first. Danny Robinson does something similar with his *new* controll / component Thanks, Matthias On 1/30/07, Mark Robinson [EMAIL PROTECTED] wrote: Hi Guys, I've finished up the packing for the Oracle Skin. Is there a sandbox/upload region available? Mark
Re: JBoss Seam Trinidad integration
Pete, Hey, I'd be thrilled to see some better integration. On the subject of paging, et al: what'd be wonderful is a solid implementation of the Trinidad CollectionModel API, that could handle the following issues: (1) Page in data as necessary, automatically (2) Report good permanent row keys, so that adding/removing rows gets picked up without any off-by-one errors. (3) Perform sorting directly on the model -- Adam On 2/1/07, Peter Muir [EMAIL PROTECTED] wrote: Hello there, I'm hoping to do some work to improve the integration of Seam and Trinidad. I've tried to explain the various Seam specific bits but I'm very happy to clarify :) Firstly, issues that I know of (and have been reported by Seam users): * Seam has a tag validateAll, which traverses down the JSF component tree looking for UIInput components and adding a validator to them (just saves you having to add the validator to each UIInput). This can be fixed in Seam (http://jira.jboss.org/jira/browse/JBSEAM-501) * There is a problem outjecting (this is Seam's way of making an object available in JSF) a Trinidad TreeModel (none of the children appear). It works quite happily (for example) if you outject an object, and then convert it to a (ChildProperty)TreeModel in a facelets function. Anyone got any ideas? Or do I need to dig into this ;) * Seam uses some EL enhancements (by Stan Silvert) to allow passing of method parameters. These don't work when you use Trinidad BUT I don't think this is worth fixing as there is supposed to be an enhancement to EL (by Jacob Hookom) becoming available that will allow method parameters to work anyway (http://jira.jboss.org/jira/browse/JBSEAM-697) Secondly, a few ideas for making the two frameworks work better together - my suggestion is to distribute these with Seam as jboss-seam-trinidad.jar - an optional jar you could include in your project to get this extra functionality. 1) @TreeModel @TreeModelSelection The idea here is that in your Java code you could do something like @TreeModel(childProperty=children) private ListFoo foo; and then, in your view, it would be magically converted to a tree model. Further, when an action is called from the view, if one of the nodes of the tree was selected, a property annotated with @TreeModelSelection would contain the object representing the node. This already works with datamodels so should be straightforward. 2) Data paging: Seam includes the ability to page through a query, only retrieving that pages worth of records from the persistence layer BUT it requires quite a lot of controls on the front end. Trinidad has good paging controls BUT will load all the data and then page in JSF. It would be good to get the best of both and make trinidad request only the records it needs. My initial ideas about achieving this are: add in some sort of PagingController which Seam could override to do its paging or Use the existing-in-Trinidad RangeChangeEvent to alter query parameters 3) Perhaps an @MenuModel annotation (similar to treemodel) Thirdly, once you guys have any sort of release out (that we can say to Seam users - use this version), we'll add an example of using Trinidad and Seam to the set of Seam examples. I'd like to hear of any incompatibilities you know about and any other integration ideas you guys have :) Also, it would be great to hear how close the areas I've mentioned above are to being in their final form or whether there is a lot of refactoring to do. I'm tracking this via http://jira.jboss.org/jira/browse/JBSEAM-754 Thanks Pete
Re: [Skinning] CSS selector limit hit in IE
Having magic insider knowledge of the scenario where this
problem occurs :), one of the major causes of it is
using different keys for the same CSS rules. For example,
we use af|selectManyShuttle and af|selectOrderShuttle,
but they're basically the same thing. Merging the
compressed versions of those keys would be a major
win.
This is tricky for classes that are used in complex
selectors, but for classes that only show up in simple
selectors, we could potentially detect the match,
-- Adam
On 1/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
Well, it turns out that IE has a limit to the size of a CSS file. It's
not the actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095
CSS selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that
we've built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors
after the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our
style selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to
the quick fix when I have more time.
Or, I'll be forced to do this solution if the above solution can't be
done for some reason.
Anyway, let me know what you think about the fixes. I'll start
investigating it to make sure it is possible and won't break
anything. My main concern was if people were using our public style
classes, like styleClass=.AFInstructionText, but
it looks like we compress these when we are in compressed mode.
Let me know if there are other things I should check.
Thanks,
Jeanne
Re: [Skinning] CSS selector limit hit in IE
One more thing: what I really like about having
both the compressed and uncompressed style
classes is that when I see a class in the source,
I can figure out what the real .css style is.
Is there any way we could - at least in debug mode -
leave behind a .css comment with the original
class name?
-- Adam
On 1/31/07, Adam Winer [EMAIL PROTECTED] wrote:
Having magic insider knowledge of the scenario where this
problem occurs :), one of the major causes of it is
using different keys for the same CSS rules. For example,
we use af|selectManyShuttle and af|selectOrderShuttle,
but they're basically the same thing. Merging the
compressed versions of those keys would be a major
win.
This is tricky for classes that are used in complex
selectors, but for classes that only show up in simple
selectors, we could potentially detect the match,
-- Adam
On 1/30/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
Well, it turns out that IE has a limit to the size of a CSS file. It's
not the actual size of the file, but rather it is the
# of CSS selectors. I did a test and found out that the limit is 4095
CSS selectors.
Firefox doesn't appear to have a limit.
As you may know, the CSS file we generate contains both compressed and
uncompressed styles, like this:
.af_inputText_content, .x01 {background-color: blue}
Our renderers render a shortened styleclass, unless
the DISABLE_CONTENT_COMPRESSION flag is set to true in web.xml, then it
renders the long styleclass.
input class=x01...
Ok, that's the background.
*The problem* is that because we have a lot of custom components that
we've built on top of Trinidad, and our customers
have built custom components, etc, and these all have skinning,
we have bumped up against the 4095 selector limit in IE. All selectors
after the 4095th one are ignored.
*A quick fix*, and probably a good one for a long time, is to render the
styles in compressed mode when compression is on,
or in uncompressed mode when compression if off. That will reduce our
style selectors by 1/2, and will help performance to boot. :)
I can also add a warning if we go past 4095 selectors for IE.
Another solution is to break up the file into multiple files when I've
reached the limit in one file, and include
all the css files into the rendered page. I can do this in addition to
the quick fix when I have more time.
Or, I'll be forced to do this solution if the above solution can't be
done for some reason.
Anyway, let me know what you think about the fixes. I'll start
investigating it to make sure it is possible and won't break
anything. My main concern was if people were using our public style
classes, like styleClass=.AFInstructionText, but
it looks like we compress these when we are in compressed mode.
Let me know if there are other things I should check.
Thanks,
Jeanne
Re: unknown-version in generated css file
Jeanne,
There's a better way. See:
http://maven.apache.org/plugins/maven-jar-plugin/examples/manifest-customization.html
Starting with version 2.1, the maven-jar-plugin no longer creates the
Specification and Implementation details in the manifest by default.
If you want them you have to say so explicitly in your plugin
configuration:
project
...
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
...
configuration
archive
manifest
addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries
addDefaultImplementationEntriestrue/addDefaultImplementationEntries
/manifest
/archive
/configuration
...
/plugin
/plugins
/build
...
/project
-- Adam
On 1/29/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Ok, I figured out what is going on.
If we want our manifest.mf file in our jar to show the implementation
version, then we need to:
1. Add a manifest.mf file in the META-INF directory that has the
implementation-version in it.
2. Add this configuration element to the pom.xml file:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-jar-plugin/artifactId
*configuration
archive
manifestFilesrc/main/resources/META-INF/MANIFEST.MF/manifestFile
/archive
/configuration*
executions
execution
goals
goaltest-jar/goal
/goals
/execution
/executions
/plugin
We are missing both of these.
Does anyone object to my adding this to get our version in the
manifest.mf that's in the jar?
Should I do this for the api jar as well?
What should the version string be? This string will be in the generated
css file, at least for now. I plan to raise
another issue regarding the version string in the filename, but that can
wait.
Thanks,
- Jeanne
Jeanne Waldman wrote:
I know how this could work (is supposed to work?), because we are
doing something similar in our internal project . We have a
MANIFEST.MF file in the impl's META-INF directory that defines
implementation-version, and I think mvn automatically appends this
information into the impl jar's MANIFEST.MF file.
In Trinidad, though, I don't see this MANIFEST.MF file in the impl's
META-INF directory. If I add it myself, do mvn clean install, it still
doesn't work. But then after looking into it for our internal project,
I found that it stopped working recently there, too.
Anyway, Bud and I are looking into it, and I'll keep you posted. If
you know something that I am missing, let me know. :)
Thanks,
Jeanne
Jeanne Waldman wrote:
Hi Adam,
That's what I figured based, but I don't see the implementation
version in the manifest.mf.
So I should have asked, how does it get in the manifest.mf file?
Maybe I'm not building the jars with the correct flag.
I'm using mvn install jdev:jdev.
- Jeanne
Adam Winer wrote:
The implementation version is defined in the manifest;
since we're going from the StyleSheetDocumentParser's
Package object, that should be the trinidad-impl.jar's
MANIFEST.MF file.
-- Adam
On 1/19/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I see that when I run a demo jspx file, the generated css file has
unknown-version in the name.
The reason, I believe, is that the
'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if (${trinidad-version}.equals(_documentVersion))
{
ClassStyleSheetDocumentParser implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) (implPkg.getImplementationVersion()
!= null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = unknown-version;
}
}
Re: Early Prototype - Dialog using DHTML / iFrame
Danny,
I grabbed the patch, made a branch, and applied it. I fixed up
some things:
- Moved (almost) all of the popup dialog and panel popup JS code into
TrPanelPopup and TrPopupDialog wrapper objects
- Fix coding convention problems: no tabs allowed, braces on new lines
- Instead of removing the code that launched new windows for dialogs, hide
it behind a web.xml context init parameter (currently defaulting to the old
style)
- Use resource bundle for translatable contents
- Load JS automatically
There's plenty to do still, most importantly:
- Implement sizing correctly
- Populate title of the popup based on the title of the dialog's content
- Most importantly, for popup-based dialogs, do not use a FRAMESET
inside of the IFRAME; just use the IFRAME
But, that said: cool stuff!
I think before we could look at merging anything into trunk,
we'd need an Apache licensing agreement signed off on (because
it's a non-trivial chunk of code...)
-- Adam
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Patch file available here: http://thefoxberry.com/
Only note, is that this also contains the panelPopup component, and that
you'll need to include the two .js files into the servlet that merges the
common javascript. If I get chance later, I'll do this and repost the
patch.
Should work fine in Firefox or IE, others are untested.
Danny
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
I'll post up a .patch file later today.
I used custom .js for the dialog, as I wasn't sure how we'd go about
integrating a 3rd party lib, and the few I looked at didn't quite fit right,
or had license issues. Besides, it was good practice. However, if we have
a library that we're trying to integrate with on a larger scale, then I
think it makes sense.
D.
On 1/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
HEy Danny,
two things;
1) the image looks great.
2) do you use one of these days upcoming ajax-ish JavaScript libs?
(or custom JS?)
Another one, will you also provide the source in somewhat format?
That would allow us to start with a sandbox ..
Thanks,
Matthias
On 1/30/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hey,
In a timely fashion, I've just seen Adams comments about wanting to
switch
to a DHTML/iFrame solution for dialog windows.
I've pulled together a prototype set of changes that switches the
default
implementation of dialog windows, to use a floating popup iframe. It
seems
to work well and both the date picker dialog and the number picker
demo work
without any alteration. It is implemented as a javascript component
that
inherits from the basic panelPopup component I posted a while
back. The
prototype renders an iframe that blocks access to the parent window
until
the dialog returns.
I say prototype, because I need some feedback on what is/isn't allowed
to
change inside the current dialog framework. Meaning - do we have to
introduce two modes of running, where dialogs will appear in either a
browser window, or in a DHTML iframe? Could we kill off the browser
window
version as there seems to be a very large amount of JavaScript that we
could
tear out if we did.
I'll post a war file this afternoon demonstrating how it works, but
for now
here's a quick picture and the list of changes.
http://thefoxberry.com/trinidad/trinidadpopupdialog.jpg
DialogRequest.java modified to call an alternative javascript method
for
opening the dhtml dialog. When the dialog is launched it is populated
with
the necessary properties for callback when the dialog is closed, thus
no
array of dialogs (var ADFDialogReturn = new Array()) needs to be
maintained.
function _launchPopupDialog(
srcURL,
features,
formName,
postbackId,
partial)
{
_theDialog.callback = _returnFromDialogAndSubmit;
_theDialog.callbackProps = { formNameKey:formName,
postbackKey:postbackId, partialKey:partial };
_theDialog.resize(features['height'], features['width']);
_theDialog.launchDialog(srcURL);
}
On close the dialog will call the following callback function
function _returnFromDialogAndSubmit(props, value) {
if (props)
{
var formName = props['formNameKey'];
var postbackId = props['postbackKey'];
var partial = props['partialKey'];
if (partial)
_submitPartialChange(formName, 0, {rtrn:postbackId});
else
submitForm(formName, 0, {rtrn:postbackId});
}
}
CoreRenderKit.returnFromDialog() - modified to return the following
scriptlet, which closes the dialog and causes the above callback to
occur.
scriptparent.parent.returnFromDialog();/script
Window.js - _sizeWin() function - disabled until I have time to
rework. If
left untouched it resizes the window - which because the dialog is an
iframe
means it
Re: svn commit: r500011 - /incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Has this change been tested? I'm far from certain
that this was purely an optimization. We often
check whether there is a PartialPageContext to
see if PPR is enabled, and if this check is removed,
then a lot of code will (I think) assume that PPR
is enabled and available when it is not.
-- Adam
On 1/25/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: jwaldman
Date: Thu Jan 25 14:02:08 2007
New Revision: 500011
URL: http://svn.apache.org/viewvc?view=revrev=500011
Log:
ADFFACES-364 PartialPageContext optimization bug. Check in for Scoot O'Bryan to
jwaldman-portal branch.
Remove this optimization in _initializePPR:
// Don't bother if PPR isn't even supported
if (!CoreRendererUtils.supportsPartialRendering(this))
return;
The reason is commented in the code:
//There used to be an optimization here which would simply return when
//the PartialRendering capabilities were disabled. This was removed
//because it is possible for extensions to Trinidad to support PPR in a
//container-specific way in a Portal Environment even though such capability
//is off by default. Furthermore, the check on whether something is a
//PPR request or not is very efficient, so there is very little time saved
//by the optimization.
Modified:
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Modified:
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java?view=diffrev=500011r1=500010r2=500011
==
---
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
(original)
+++
incubator/adffaces/branches/jwaldman-portal/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderkit/core/CoreRenderingContext.java
Thu Jan 25 14:02:08 2007
@@ -466,9 +466,13 @@
FacesContextfContext,
RequestContext context)
{
-// Don't bother if PPR isn't even supported
-if (!CoreRendererUtils.supportsPartialRendering(this))
- return;
+//There used to be an optimization here which would simply return when
+//the PartialRendering capabilities were disabled. This was removed
+//because it is possible for extensions to Trinidad to support PPR in a
+//container-specific way in a Portal Environment even though such
capability
+//is off by default. Furthermore, the check on whether something is a
+//PPR request or not is very efficient, so there is very little time saved
+//by the optimization.
PartialPageContext partialPageContext =
PartialPageUtils.createPartialPageContext(fContext,
Problems with tables and transient components - should be fixed
Some long-standing problems with tr:tables that contain transient components - problems that have bit Facelets users with extra whitespace! - etc., should hopefully be fixed as of code just checked in. If anyone still has problems after upgrading, please let me know. There's still an open bug regarding NullPointerExceptions when the table has a comment directly in it, which I haven't looked into. Cheers, Adam Winer
Re: SortableModel should use Collator for sorting strings
+1 to having *some* solution here. Perhaps SortableModel should have support for Comparators (which is implemented by Collators). One possible API would be: public MapString, Comparator getComparators(); ... so you could do: Collator collator = Collator.getInstance(FacesContext.getCurrentInstance().getViewRoot().getLocale()); model.getComparators().put(myField, collator); This would require manual setup per field, though. But I think it would solve the problem we have right now where we don't know how to sort a column if the first entry is null. Another possibility is adding a protected hook: protected Comparator getComparator( String fieldName, Object sampleObject); Manual setup again, but at least you could write one class that had it turned on for all Strings. And yet another way of doing this would be automatically using Collator.getInstance() for Strings, or adding a flag to turn it on - I'm not well-versed in the performance implications of using Collator, and would want to know before turning this on by default. And it's not obvious that you would always want it on - I could imagine that some strings might want to be sorted in a non-internationalized manner. Ideas, preferences? -- Adam On 1/21/07, Martin Koci [EMAIL PROTECTED] wrote: Hello, I trying to use SortableModel instead my own implementation, but it has one big issue - doesn't support Czech language. We (here in the middle of Europe) have very special rules for sorting words which cannot be done with simple: value1.toString().compareTo(value2.toString()) Fortunately java has a build-in support with Collator: Collator collator = Collator.getInstance(FacesContext.getCurrentInstance().getViewRoot().getLocale()); collator.compare(value1, value2); Should I create a JIRA issue? Thanks, Martin For experts and czech native speakers :D http://146.102.68.23/kizi/IKSy/kap12.htm
Re: unknown-version in generated css file
The implementation version is defined in the manifest;
since we're going from the StyleSheetDocumentParser's
Package object, that should be the trinidad-impl.jar's
MANIFEST.MF file.
-- Adam
On 1/19/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi,
I see that when I run a demo jspx file, the generated css file has
unknown-version in the name.
The reason, I believe, is that the 'implPkg.getImplementationVersion()'
in the below code is returning null.
Why is this? Where are we setting (or supposed to be setting) the
implementation version exactly?
Does anyone else see this problem?
I think this code was added in this JIRA issue:
http://issues.apache.org/jira/browse/ADFFACES-147.
Thanks,
Jeanne
// If the document version is ${trinidad-version}, replace it
// with the version number right out of our manifest
if (${trinidad-version}.equals(_documentVersion))
{
ClassStyleSheetDocumentParser implClass =
StyleSheetDocumentParser.class;
Package implPkg = implClass.getPackage();
if ((implPkg != null) (implPkg.getImplementationVersion() != null))
{
_documentVersion =
implPkg.getImplementationVersion().replace('.','_');
}
else
{
_documentVersion = unknown-version;
}
}
Re: [JSF 1.2] setXxx Methods on ExternalContextDecorator
In the JSF 1.2 branch, yep, we have to.
-- Adam
On 1/16/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
hi,
in jsf 1.2 there are four new setXxx() methods available on the
externalCtx clazz.
Do we need to add them to our ExternalContextDecorator, like:
@Override
public void setResponse(Object response)
{
getExternalContext().setResponse(response);
}
?
-M
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: svn commit: r495895 - /incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XhtmlResponseWriter.java
Whoa there! We can't make this change in JSF 1.1.
In JSF 1.1, flush() has a very specific mixed meaning because
of the interweaving of JSP execution and UIComponent rendering.
flush() means some ordinary JSP output may be coming,
so flush all buffered ResponseWriter content.
In JSF 1.2, flush() can mean something normal. So,
I think this change needs to be rolled back from 1.1
and applied to 1.2 only (to all ResponseWriters, not
just XhtmlResponseWriter).
-- Adam
On 1/13/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: matzew
Date: Sat Jan 13 04:54:54 2007
New Revision: 495895
URL: http://svn.apache.org/viewvc?view=revrev=495895
Log:
added _out.flush() = ADFFACES-352
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XhtmlResponseWriter.java
Modified:
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XhtmlResponseWriter.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XhtmlResponseWriter.java?view=diffrev=495895r1=495894r2=495895
==
---
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XhtmlResponseWriter.java
(original)
+++
incubator/adffaces/trunk/trinidad/trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/io/XhtmlResponseWriter.java
Sat Jan 13 04:54:54 2007
@@ -87,6 +87,7 @@
public void flush() throws IOException
{
_closeStartIfNecessary();
+_out.flush();
}
Re: release plan
And, I'd love to have the JSF 1.2 version released too - plugins and Trinidad itself - 'cause that's what I'm spending most of my time working with these days. I think that the full process for release should be: FOR PLUGINS: - Create m1 branch of plugins - Update version in POM of plugins trunk to m2-SNAPSHOT - Vote on releasing plugins, if approved by incubator, then: - Update version in POMs of m1 branch to remove SNAPSHOT - Release plugins BETWEEN THE PLUGINS AND TRINIDAD: - Update Trinidad trunk to point at m1, non-snapshot plugins *or* to m2-SNAPSHOT, depending on how confident we are FOR TRINIDAD: - create m1 branch of Trinidad - Update version in POM of Trinidad trunk to m2-SNAPSHOT - Vote on releasing Trinidad, if approved by incubator - Update version in POMs of m1 branch to remove SNAPSHOT - Release Trinidad These'll be consecutive, but in the future should in theory be totally disconnected. How's this sound? -- Adam On 1/12/07, Bruno Aranda [EMAIL PROTECTED] wrote: Yes, thanks Matthias for opening the thread. As you point out, we will need to have the jsf 1.2 maven-faces-plugin released when the jsf myfaces implementation is ready. Cheers, Bruno On 12/01/07, Matthias Wessendorf [EMAIL PROTECTED] wrote: Hi, I have the following release plan in mind: -getting the JSF 1.1 plugins release out (needs approval by the Incubator PMC) -making Trinidad core (the /trinidad folder) depend on them and deploy a RC for the M1 of core -getting the JSF 1.1 core release out (needs approval by the Incubator PMC) doing the same procedure for the JSF 1.2 bits. Why JSF 1.2? Because your friends at MyFaces currently working on JSF 1.2 release and at least they need a *release* version of the JSF 1.2 plugins to get a RC1 out for that. An Apache policy says no -SNAPSHOT dependencies in a release. comments? -M -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: immediate=true is ignored when auto submitting input components
No, the code in UIXEditableValue is 100% correct, and there are no double validations, and this has nothing to do with any of the problems you're seeing. If immediate is true on an EditableValueHolder, it means that validation moves up from Process Validators to Apply Request Values; that's exactly what the code does. The bug is invalid - what you need to do is call FacesContext.renderResponse() from a valueChangeListener, to avoid continuing the lifecycle. -- Adam On 1/9/07, David Brunette [EMAIL PROTECTED] wrote: Hi everybody. I have created the following bug: https://issues.apache.org/jira/browse/ADFFACES-349. If I have a simple page with, for example, a tr:selectOneChoice autoSubmit=true immediate=true /, whenever I change the value of the dropdown, I am getting a error messages for all of the other components in that page that are required or have other validation errors... even though I have set immediate=true. This attribute seems to be ignored. I have looked into the UIXEditableValue class, and is seems to be a simple mistake in the processDecodes() method... it is calling: if( isImmedate() ) _executeValidate(context); That seems backwards, and a '!' should probably be put into the if condition so that the validations are executed if the component is NOT immedate. But then I noticed that the _executeValidate() method is also being called by the processValidations() method of this same class. Does it make sense that we are executing the validations twice? I would think that we only wanted to do that once, but I do not know if there is an actual reason for having this call in both methods. I have not submitted a patch to the bug I created because I would first like to know if the proper fix is to 1) fix the if condition in the processDecodes() method, or 2) remove the call to _executeValidate() from the processDecodes() method and just let processValidations() handle it. Any suggestions are welcome. Thanks... Dave The information transmitted herewith is sensitive information of Chordiant Software or its customers and is intended only for use to the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon, this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.
Re: [PORTAL] Adamns inline questions
-- Adam On 12/27/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Adam, In your last checkin to my branch you made some comments I would like to address. In the DispatchResponseConfiguratorImpl there is an isApplied function. You were asking why it was there. The reason for this is simple.. Backward compatibility. You mentioned to me in some previous emails that the filter was needed for backward compatibility and that any wrappers which WERE handled by the filter, needed to continue to be handled by the filter. Likewise, in many instances, the use of the filter is optional and until the JSR-301 is complete, Portal environments won't have access to pre-lifecycle requests and whatnot. So the isApplied simply tells whether the wrapper has been applied or not. If it has (in the case of the filter or other wrapping mechanisms like Portlet Filters (JSR-286) or Bridge listeners (JSR-301)) then it doesn't apply it a second time when the ExternalContext is retrieved. If this hasn't been pre-initialized then it does. OK, I see that - but a much simpler way of going about this is to run the GlobalConfiguratorImpl *as a whole* from the Filter and move this have I run? stuff into just GlobalConfiguratorImpl. This code is REALLY only needed for backward compatibility and any Configurators going forward would not be dependant on the filter and therefore would not need to worry about whether it was applied or not. No, it's not just backwards compatibility; the point is that it is perfectly acceptable for a developer to write a servlet filter. Just because you or I may want to require portlet support doesn't mean everyone does, or that everyone on the planet should stop using servlet filters. So, we should support those that want to write servlet filters to the extent that it's feasible, or those that want to integrate pre-existing filters to the extent that it's feasible. Which it is, as best I can see. In FileUploadConfiguratorImpl you added a fixme that we should clean up the handles to the files as soon as possible. I agree with this. The current implementation (ie. before configurators were added) applied these before execution of the filterchain and then was allowed to get GC'd after. I believe that doing the same logic inside of the beginRequest and endRequest has about the same lifespan. So my question is, how does this differ from what was provided by Trinidad before these enhancements? If it isn't any different, then maybe we can file a Jira ticket and handle this as part of another patch. Yep, if it's endRequest(), that's good enough (as long as our configurator code has absolute guarantees that endRequest() will be called, which it does, I think?) -- Adam Are these acceptable or are these something that need to be changed for this patch? Scott
Re: [Skinning Enhancement] -tr-icon-class or equivalent
I think, for now, that I'm OK with just requiring inline specification
of the styles - that feels a lot more natural in a CSS file.
At least, as long as it works. :)
-- Adam
On 12/27/06, Jeanne Waldman [EMAIL PROTECTED] wrote:
Hi there,
I see the need to render
img class=someClass width=10 height=8/
when we render a skinning icon.
However, there is currently not a way to specify a styleclass in the
skin css file, although we do have a Java API to do this.
We could do something like:
af|foo::some-icon {
content: url(/path/cat.gif);
-tr-icon-class: someClass;
}
Let me know if you think I should/shouldn't open an JIRA enhancement for
this.
This isn't a critical bug, since the workaround is to use css properties
inline, and we parse those up and render an inline style property like this:
af|foo::some-icon {
content: url(/path/cat.gif);
background-color: blue;
display: block;
}
renders:
img style=background-color:blue; display:block .../
(or should... there's a bug that I filed that I plan to fix where it
only renders the last css property.)
Thanks,
Jeanne
Re: [PORTAL] Changes and API review?
initialization at that stage. This is something that very well could become a problem. And I haven't even taken a look at how you handled the isInRequest functionality that I need to maintain the proper flexibility in the portal case. Still, I really don't have time to argue these points. I'll just have to generate Jira tickets as problems come up and we'll have to change the API's if we need to change them. All I really have to say about the subject is allowing the GlobalConfigurator implementation handles all these issues for free. And using my latest checkins handles most of them, just not as cleanly. Certainly. though, a lot more cleanly then using the Service Loader. You said that you didn't know if these changes worked in a portal environment, and I'm not real sure I can confirm that within the next week or so. But checking in changes to a portal compatibility branch without being able to check them in a Proof of Concept (POC) is really damaging to the project being that Portal compatibility is what this project is all about. I was able to test my stuff as a POC using the Oracle Portal and Bridge, and I'm also aware of the changes that need to be made in the MyFaces Bridge to support these cases. Many of these issues ARE going to be addressed in JSR-301 but my hope it to have the myfaces bridge up to par before that time. My final, and I mean final, comment on this is that it is important to me to have error checking on disableConfiguratorServices. That's from a robust API perspective. From a Portal standpoint, it is far more important for me to have control over the initialization logic and to error out of getInstance when an instance is not available (or return null, I don't care which) then it is for me to have an exposed getInstance() in the API and for the thing to return a dummy configurator. Exposing the getInstance made sense when we had the ability to tack additional non-static API's onto the GlobalConfigurator. Since we don't, I can't see ANY reason why someone would need this API outside of Trinidad. The object is simply not useful outside of this codebase anymore. Plus it keeps us flexible to add an API later if we need one whereas this current implementation LOCKS us in to providing a plain run-of-the-mill configurator. Lastly, for GOD sake, don't use the service loading system to load this class. The Service loading system is great for making extensions to Trinidad, but it has limitations which stem from the fact that order within these services is not guaranteed. For now I say we simply have the GlobalConfiguratorImpl (in the Impl package) be referenced directly if we need to, and if we have the need to add additional globalConfigurators in the future, we can come up with an API that makes sense. This one makes no sense at all. Essentially I outlined for you the things in my last checkin. You're latest checkin' will lock us into unwanted implementations, implementations that make NO sense what so ever, and implementations that are not robust. As I stated before, though, I don't really have time to argue with you anymore. I have some other projects that I need to work on at the moment. So if you're happy with the API, call a vote and let's get this moved in so I can move forward and we can hopefully have trinidad working inside of a MyFaces Portal environment sometime this century. Scott O'Bryan Adam Winer wrote: On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adam, Well, you basically implemented one of the solutions I said I didn't like earlier, but oh well. And there are a number of places you need to cast. So the concerns are still valid. Well, I don't get that claim, as I didn't add a single cast in my patch at all, and removed references to the impl class, so I can't imagine how I've made things worse. And I didn't really see any casts that were already there. The one question I do have is why does getInstance take in an ExternalContext? I'm assuming it's because your executing the init inside of the getInstance object and I'm not sure this is the correct place for this. My hope in all of this was to be able to explicitly handle initialization of this object. Plus, nine times out of ten, the ExternalContext object is ignored in the call to this method. A create + initialize construct is more robust than a create-and-hope- it-gets-initialized-by-someone-else construct. -- Adam Either way, don't see as I really have the time to argue. So is it acceptable to everyone? Also, there is no Adam Winer wrote: Scott, OK, well, I just went ahead and implemented what I was trying to say, to see if I'd run into the problems you're describing. I didn't... (It's possible I've broken something in portlet land - I only tested the changes in a servlet environment.) On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adding getInstance() to the configurator will either force us to cast in a bunch of different
Re: [PORTAL] Changes and API review?
Scott, OK, well, I just went ahead and implemented what I was trying to say, to see if I'd run into the problems you're describing. I didn't... (It's possible I've broken something in portlet land - I only tested the changes in a servlet environment.) On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adding getInstance() to the configurator will either force us to cast in a bunch of different places No, it doesn't. No casts were required at all, much less in a bunch of places, and most of the code now doesn't even have references to the impl class at all. or to expose the GlobalConfiguratorImpl's api to the rest of the world (which I don't want to do because they are applicable ONLY to global configurator. And it won't lock us into an API we may have to expand later. As for simply putting the Boolean on the request map, either I'll have to make a protected constant on the Configurator interface (which has no bearing on any of the configurators except the global configurator so it shouldn't go into the ancestor) or I add a porotected (isDisabled) method (which, again, is only applicable to the GlobalConfiguratorImpl and therfore shouldn't do into it's Ancestor). See the code checked in, which does not suffer these probems. I've never been one to include a feature into an interface or a class that is applicable in only one instance of that class because it violated basics OO design principals. The only other option I see here is to define the constant used to store the boolean in BOTH classes and hope they remain in sync, but I've never been a big fan of that either. Again, see the code checked in. -- Adam
Re: [PORTAL] Changes and API review?
On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adam, Well, you basically implemented one of the solutions I said I didn't like earlier, but oh well. And there are a number of places you need to cast. So the concerns are still valid. Well, I don't get that claim, as I didn't add a single cast in my patch at all, and removed references to the impl class, so I can't imagine how I've made things worse. And I didn't really see any casts that were already there. The one question I do have is why does getInstance take in an ExternalContext? I'm assuming it's because your executing the init inside of the getInstance object and I'm not sure this is the correct place for this. My hope in all of this was to be able to explicitly handle initialization of this object. Plus, nine times out of ten, the ExternalContext object is ignored in the call to this method. A create + initialize construct is more robust than a create-and-hope- it-gets-initialized-by-someone-else construct. -- Adam Either way, don't see as I really have the time to argue. So is it acceptable to everyone? Also, there is no Adam Winer wrote: Scott, OK, well, I just went ahead and implemented what I was trying to say, to see if I'd run into the problems you're describing. I didn't... (It's possible I've broken something in portlet land - I only tested the changes in a servlet environment.) On 12/21/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adding getInstance() to the configurator will either force us to cast in a bunch of different places No, it doesn't. No casts were required at all, much less in a bunch of places, and most of the code now doesn't even have references to the impl class at all. or to expose the GlobalConfiguratorImpl's api to the rest of the world (which I don't want to do because they are applicable ONLY to global configurator. And it won't lock us into an API we may have to expand later. As for simply putting the Boolean on the request map, either I'll have to make a protected constant on the Configurator interface (which has no bearing on any of the configurators except the global configurator so it shouldn't go into the ancestor) or I add a porotected (isDisabled) method (which, again, is only applicable to the GlobalConfiguratorImpl and therfore shouldn't do into it's Ancestor). See the code checked in, which does not suffer these probems. I've never been one to include a feature into an interface or a class that is applicable in only one instance of that class because it violated basics OO design principals. The only other option I see here is to define the constant used to store the boolean in BOTH classes and hope they remain in sync, but I've never been a big fan of that either. Again, see the code checked in. -- Adam
Re: [PORTAL] Changes and API review?
Scott, Why wouldn't methods that hook the start and end of the physical request be generically useful? Note that in my scheme, these'd just be empty methods, not abstract methods (or interface methods) that every configurator has to implement. For that matter, wouldn't we want to make the configurator - right off the bat - *only* hook the physical request? What's the use case for ever wanting to hook the action and render phases independently (via this API, that is)? -- Adam On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Adam, First off, thanks for responding. Your suggestions have been invaluable. :) Now... Adam Winer wrote: So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. I absolutely can but bear with be because, like many of the Portal usecases, it's kinda convoluted.. One thing currently being discussed in JSR-301 (just as an example) is the lifetime of a Request attribute. Consider, if you will, the Servlet case. A request attribute has a lifetime of the physical request. This is sufficient because the application is assumed to be the only application in the browser. This means that every physical request from the browser to the server should process the actions on the JSF lifecycle and then execute the Render. In a Portal, however, this case is different. Really, request attributes that were added during the Lifecycle.execute phases are assumed to be there during each call the the Lifecycle.render phases. And because there is more then one portlet on the screen, an action from another portlet may cause a render to happen on our JSF Application. Understanding that, the nature of the two phase request of the portal is such that the JSR-301 bridge might (TBD) execute the beginRequest and endRequest methods at the beginning and end of the action AND render phases rather then at the beginning and end of the physical request. I'm pushing for the latter, but there are people that know a lot more about Portal's then I do who are arguing the previous point. So one of the things I put on the GlobalConfigurator initially (and I might need to put it back after I'm able to test this with the Bridge enhancements I need and Pluto), was a set of methods to store and clean up these items on the physical request. There is no reason that the baggage for this should have to be carried around by each Configurator. And if we have a getGlobalConfigurator which simply returns a Configurator object now, we're going to have problems in the future if that changes. Plus, it's one class of extra bloat, there are no real debatable API's on it that lock us into anything, and there is no impact at runtime to support this this class. It does, however, provide us a needed layer of abstraction in an area that's still somewhat high risk. Scott
Re: [PORTAL] Changes and API review?
That method could easily be a static method on Configurator in my scheme. -- Adam On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I just got one more example from your other input. I'm probably going to be adding a disableConfiguratorForRequest method (or something similar) to the global configurator to support disabling the configurator services from running. It's cleaner then an attribute me-thinks and will help if we run into scoping issues with the two part portal request. See, I'm already going to need it. Scott Scott O'Bryan wrote: Hey Adam, First off, thanks for responding. Your suggestions have been invaluable. :) Now... Adam Winer wrote: So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. I absolutely can but bear with be because, like many of the Portal usecases, it's kinda convoluted.. One thing currently being discussed in JSR-301 (just as an example) is the lifetime of a Request attribute. Consider, if you will, the Servlet case. A request attribute has a lifetime of the physical request. This is sufficient because the application is assumed to be the only application in the browser. This means that every physical request from the browser to the server should process the actions on the JSF lifecycle and then execute the Render. In a Portal, however, this case is different. Really, request attributes that were added during the Lifecycle.execute phases are assumed to be there during each call the the Lifecycle.render phases. And because there is more then one portlet on the screen, an action from another portlet may cause a render to happen on our JSF Application. Understanding that, the nature of the two phase request of the portal is such that the JSR-301 bridge might (TBD) execute the beginRequest and endRequest methods at the beginning and end of the action AND render phases rather then at the beginning and end of the physical request. I'm pushing for the latter, but there are people that know a lot more about Portal's then I do who are arguing the previous point. So one of the things I put on the GlobalConfigurator initially (and I might need to put it back after I'm able to test this with the Bridge enhancements I need and Pluto), was a set of methods to store and clean up these items on the physical request. There is no reason that the baggage for this should have to be carried around by each Configurator. And if we have a getGlobalConfigurator which simply returns a Configurator object now, we're going to have problems in the future if that changes. Plus, it's one class of extra bloat, there are no real debatable API's on it that lock us into anything, and there is no impact at runtime to support this this class. It does, however, provide us a needed layer of abstraction in an area that's still somewhat high risk. Scott
Re: Include JavaScriptlets in Trinidad Component which is executed once per page
You can use ExtendedRenderKitService.addScript(). -- Adam On 12/17/06, Böhringer Jochen [EMAIL PROTECTED] wrote: Hello, I am still in the development process of my Trinidad Drag and Drop Component. The dropzone calls an action method if a draggable object is dropped on it. It works fine if I omit a partial page rendering. But if I only want to execute a PPR the Javascript makes problems on the client side. For Initialization I have to execute a JavaScript each time new draggables and dropzones appear on the page or disappear. But not for every of these components only once for all of them. If I initiate a full page reload this can be done by including a scriptlet in the header of the page. But if a PPR is executed the header of the page is not executed again. Only new scriptlets which are included in the renderer's output of the components related to the PPR. Is there a hook I can use in the PPR mechanism to execute a javascript method after the ppr took place? Regards Jochen
Re: [PORTAL] Changes and API review?
Well, in this specific instance, it therefore doesn't bloat every configurator, since it only appears in one location. -- Adam On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I'm still wondering why we should bloat the API of every configurator. And not ALL of the methods I'm looking at adding here can be static. Scott Adam Winer wrote: That method could easily be a static method on Configurator in my scheme. -- Adam On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I just got one more example from your other input. I'm probably going to be adding a disableConfiguratorForRequest method (or something similar) to the global configurator to support disabling the configurator services from running. It's cleaner then an attribute me-thinks and will help if we run into scoping issues with the two part portal request. See, I'm already going to need it. Scott Scott O'Bryan wrote: Hey Adam, First off, thanks for responding. Your suggestions have been invaluable. :) Now... Adam Winer wrote: So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. I absolutely can but bear with be because, like many of the Portal usecases, it's kinda convoluted.. One thing currently being discussed in JSR-301 (just as an example) is the lifetime of a Request attribute. Consider, if you will, the Servlet case. A request attribute has a lifetime of the physical request. This is sufficient because the application is assumed to be the only application in the browser. This means that every physical request from the browser to the server should process the actions on the JSF lifecycle and then execute the Render. In a Portal, however, this case is different. Really, request attributes that were added during the Lifecycle.execute phases are assumed to be there during each call the the Lifecycle.render phases. And because there is more then one portlet on the screen, an action from another portlet may cause a render to happen on our JSF Application. Understanding that, the nature of the two phase request of the portal is such that the JSR-301 bridge might (TBD) execute the beginRequest and endRequest methods at the beginning and end of the action AND render phases rather then at the beginning and end of the physical request. I'm pushing for the latter, but there are people that know a lot more about Portal's then I do who are arguing the previous point. So one of the things I put on the GlobalConfigurator initially (and I might need to put it back after I'm able to test this with the Bridge enhancements I need and Pluto), was a set of methods to store and clean up these items on the physical request. There is no reason that the baggage for this should have to be carried around by each Configurator. And if we have a getGlobalConfigurator which simply returns a Configurator object now, we're going to have problems in the future if that changes. Plus, it's one class of extra bloat, there are no real debatable API's on it that lock us into anything, and there is no impact at runtime to support this this class. It does, however, provide us a needed layer of abstraction in an area that's still somewhat high risk. Scott
Re: [PORTAL] Changes and API review?
On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote: The global configurator already treats the render and action request as a single entity. The real question comes in about what happens during subsequent render requests. Sometimes, like storing render attributes, you want the request attributes to hang around for an action request and each subsequent render. Other times, you want it to only hang around for the physical request. This is something that the Servlet container does not address. I don't think you ever want request attributes to hang around for subsequent renders. Nor do I get why, if there were some funky lifecycle issues to deal with here, why every configurator wouldn't be forced to understand them and handle them. -- Adam Now that being said, I didn't say the methods were not generally applicable. They are. But there is no reason, in my opinion to pad the API with these additional methods. The global configurator (and only the global configurator) should be accessed directly. It's beginRequest, and endRequest methods will be called whenever appropriate whereas the Configurators, by contract, should only be called once per physical request (the Global configurator handles state saving). I had to add a new method to disable the GlobalConfigurator for one request (to handle the ResourceServlet case. So putting all this stuff on the base configurator object is unclean in my opinion. Especially considering that all configurators should have the same functionality for these methods so it would force us to finalize them in order to PREVENT people from overriding them in one Configurator and not in another. Scott Adam Winer wrote: Scott, Why wouldn't methods that hook the start and end of the physical request be generically useful? Note that in my scheme, these'd just be empty methods, not abstract methods (or interface methods) that every configurator has to implement. For that matter, wouldn't we want to make the configurator - right off the bat - *only* hook the physical request? What's the use case for ever wanting to hook the action and render phases independently (via this API, that is)? -- Adam
Re: Trinidad sandbox?
Nah, this really needs to be a separate project, at the same level as trinidad and plugins. There are most definitely cases where a branch is necessary, and for those we have to use branches, but separate projects mean that you can: - widely test them (they'll be built and downloadable) - the code won't bit-rot! Put it on a branch, and unless someone is actively maintaining that branch, it'll rapidly reach the point where it won't compile. The way I see it, we'll want the same structure as trinidad: trinidad-sandbox-build trinidad-sandbox-api trinidad-sandbox-impl trinidad-sandbox-demo The point there being that if the code is ever going to be merged into trunk, it has to adopt the same conventions (use the plugins to build the component and JSP, etc.) so it can be cleanly moved over. -- Adam On 12/19/06, Matthias Wessendorf [EMAIL PROTECTED] wrote: yeah, if others agree, I will create *branch* for that and play with Danny's contribution. @Danny: do you already have signed the CLA ? Contact me offline if you have questions on that -M On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote: I personally like the latter.. Unfortunately very few things can be developed in a Vacuume. At the very least it should have it's own copy of impl. Scott Matthias Wessendorf wrote: Looks like all here have already agreed on that one. What do you have in mind? a *separate* project with trinidad-api/-impl as dependency, where we can test components like the popup from danny? Or a *branch* that really acts as a sandbox to play with ideas on components and when stable (or close to it) the stuff get's merged into _core_ ? -M On 12/14/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to add a new sandbox project to trinidad, as a parallel directory to trinidad and plugins. This'd give us a place to add more substantial contributions - Danny Robinson's popup, for example - and give them time to be played around with, fixed up, APIs tweaked, etc., before moving in to the main libraries. It'd also give me a chance for committers like me to add experimental features that definitely shouldn't go into the trunk immediately, or perhaps ever (some ideas I've been toying with for multi-component validation, for example). Feedback? +1 from me. ;) -- Adam -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com
Re: [PORTAL] Changes and API review?
Scott,
You're explaining very well why you want to put this in IMPL.
And why you need a different instance that handles this on
behalf of all other configurators. You're not yet explaining
why you need a whole class to accomplish this, as opposed
to a standard decorator or CoR pattern, etc. I just don't get it.
This one global instance is going to load all other instances,
and invoke all other instances. NO ONE needs to cast to it -
it is all powerful since it is the first (and only) entry point,
and it can decide whether all the others will run or not.
(And dog slow? C'mon, you're exaggerating. Hugely.
And describing one potential implementation of one
potential design.)
Yes, I do fight against adding extra code to our
API. For good reason, ya know! Less public API is
good. And, it really worries me when I see a design
that is unlike all the other designs I've seen for this
sort of pattern. I immediately get a gut feeling that
it's not really necessary.
-- Adam
On 12/19/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
It's API bloat and I'm also going to have to store some extra privates
on some of these classes as well as expose some additional api's to
support this. I ran into another issue with not implementing the Global
configurator. Take a look at this code.
When used inside of GlobalConfiguratorImpl, the code looks something
like this:
public void disableConfiguratorServices(final ServletRequest request)
{
if(Boolean.TRUE.equals(request.getAttribute(_IN_REQUEST)))
{
throw new IllegalStateException(Request is already begun.);
}
request.setAttribute(_IN_REQUEST, _DISABLED);
}
Now all the IN_REQUEST stuff is basically there to handle proper cleanup
and some API enforcement when calling into the GlobalConfigurator's
getExternalContext method. It is only exposed through the
GlobalConfiguratorImpl. There is no reason for anyone to know about it
outside of the impl package and even then in only a few locations.
Really though, people should keep their hands off of this. If I have on
the normal configurator a getGlobalConfigurator method which returns a
configurator, I have to go though much hokeyness in order to tell
whether I'm in a request or not. Because API cannot depend on classes
in Impl, I'll need to use reflection to get at the private methods
unless I want to expose this as an API on the configurator in general
and I don't think we want to do that.
We can also just skip the validity checking and modify the attribute,
but I would think that if someone is trying to disable the Configurator
and the response has already begun, then they should be notified as soon
as possible before hokey little errors creep up. There is much in the
impl package that depends on the instance of the GlobalConfiguratorImpl
and it's silly in my opinion to have to cast it every time we need to
use an arbitrary function. And when we need functionality from this guy
in the API package (like with the ResourceServlets) the implementation
begins to look REAL ugly.
So my question is why should we have to go through all this reflection
and casting, making this system dog slow, rather then supporting the
proper API's. The amount of work I've had to put in simply to code
around these issues is amazing. And I still havn't heard any
compelling reason why THIS implementation is not good.
Scott
Adam Winer wrote:
Well, in this specific instance, it therefore doesn't bloat every
configurator, since it only appears in one location.
-- Adam
Re: Re: [PORTAL] Changes and API review?
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adam Winer wrote: Scott, My big concern is with the sheer quantity of new public APIs (that is, public classes in trinidad-api). We should be avoiding making anything public unless it is absolutely, critically necessary. Configurator APIs: I'm not completely sold on the name, but anyway, I think we should: Got another name you'd rather use? - Make Configurator an abstract class, not an interface. Make most of the methods empty, not abstract. Should be a simple fix - Add getGlobalConfigurator() to the Configurator API I'm not a big fan of this. The reason is that I keep running into instances in the Portal where I may have to add a per physical request type API. Current talk in JSR-301 is that the system will hopefully provide us with before and after request hooks which are much cleaner then phase listeners because we can do stuff before and after the lifecycle executes. The main question still in everyone's mind at this juncture is whether these will be run at the beginning and end of each portal request or the beginning and end of each physical request. Current leanings are at the beginning and end of each portal request and so there is a very real possibility that people might want to store attributes or whatnot that have the lifetime of the physical request. Therefore if these or other things arise, having an API for a global cofigurator will be more flexible in the future because we'll be able to add to this API would breaking binary compatibility. If we start returning normal Configurators form these API's it will force us to cast the object or add the methods to the base configurator object. In short, I think there are (or could be) sufficient difference between the GlobalConfigurator and the normal Configurator to justify the extra class even though the API's are not currently present. I don't see why our global configurator will have to comply with this API. It's our own thing. We don't need to comply or not comply with any external API. So, nope, please kill it. - Eliminate GlobalConfigurator and GenericConfigurator classes I can get rid of Generic Configurator, see above for Global Configurator TrinidadListener: - *Definitely* should be in impl, not in api. Register it automatically by including it in tr.tld. I was mimicking what we were doing with the Trinidad filter. But moving it to the TLD is definatly cleaner. I'll do this. All of the classes in webapp/wrappers and context/external: - Why aren't these in impl? - I don't understand at all why we could or should be implementing ServletExternalContext... that's provided by the impl. And PortletExternalContext should be provided by the bridge, or the impl as well if it supports portlets. What am I missing? I suspect these come from adding TrinidadFacesContext, so... These are valid questions and I went back and forth on this myself. The main issue is that the Configurators rely on someone being able to override the ExternalContext. And while a decorator may be sufficient for the overriding part, it's kind of silly (in my opinion) to force everyone to re-implement the pieces of the external context (such as, say, the RequestParameterMap) which is why those are public. As for the ServletExternalContext and the PortletExternalContext, if you look at the API for configurators again, they require us to supply an external context. In order to maintain compatibility with the servlet usecases that previous versions of Trinidad supported, we essentially need to construct a valid ExternalContext within the filter (Sevlet or future Portlet) and supply it to the configurators. It's better to provide implementations of these rather then rely on having to make them yourself. Now that being said, I moved the external context classes over to public as a while. While I believe we need the decorators and some of the map objects public, we can probably move the full ExternalContext implementations in impl (or in the case of the Portal one which was provided for completeness, remove it since I don't think it's used anywhere currently (I'll check). NONE of it should be public unless it is 100%, no two ways about it, absolutely required. - TrinidadFacesContext: why can't you just use the regular FacesContextFactory, as we're doing today? Almost any solution is better than duplicating large amounts of impl code. This is a very good question and one that I thought a lot about. First off, this class is used within the resource servlets. Faces itself is designed with the idea of allowing renderkits to extend the framework as they need to. In theory (and I know the reality is somewhat different), but someone could add two renderkits to a particular web-app and use them. The problem is that the FacesContextFactory takes all of these entensions into account when returning the context. From a renderkit perspective, this is good because you
Re: Re: [PORTAL] Changes and API review?
On 12/15/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Adam Winer wrote: Therefore if these or other things arise, having an API for a global cofigurator will be more flexible in the future because we'll be able to add to this API would breaking binary compatibility. If we start returning normal Configurators form these API's it will force us to cast the object or add the methods to the base configurator object. In short, I think there are (or could be) sufficient difference between the GlobalConfigurator and the normal Configurator to justify the extra class even though the API's are not currently present. I don't see why our global configurator will have to comply with this API. It's our own thing. We don't need to comply or not comply with any external API. So, nope, please kill it. Adam. Because other configurators may have to use it. That's what I'm saying. If other renderkits or renderkit extensions are build of Trinidad, we want them to be able to be able to access any utilities provided by this class. I'm not worried about the internal implementations as much as I'm worried about supporting this API going forward given the current unknowns. And frankly, I'm not sure why at the moment one extra method in one extra class is worth locking us into a pre-existing implementation that isn't sufficient to run inside of a portal that well. You MAY be 100% correct that no extensions will have to be made to this object in the future, but you could also be wrong. All I'm asking is for us to remain flexible. And at such a small cost, I don't think it's a huge issue. NONE of it should be public unless it is 100%, no two ways about it, absolutely required. ok Then set a request attribute, whatever, to turn off our wrappers. Any behind-the-scenes fiddling is WAAAY better than all of this extra code. Well it still doesn't eliminate the problems we're going to have with anyone else's stuff, and I think that's a real tradegy. But I'll pull the code out. I don't know what problems those'll be, other than hypothetically that maybe there might be perhaps. In which case, we could certainly look at that *at that point*. Adding lots of extra public code on the theory that it *might* be necessary down the road is not a good tradeoff. So I guess basically I'm making one last appeal on the GlobalConfigurator thing. If you still want it removed I'll get rid of it. But I honestly think we're backing ourselves into an unnecessary corner. I'll give in on everything else and make a new patch for the jwaldman portal branch. I just don't get how we're getting extra flexibility. Can you give me a hypothetical scenario where having a different global configurator class (rather than just an instance) proves a big win? I don't see it yet. As best as I can see, my proposal still allows full access to the global instance to external developers. It just doesn't require a bonus class to do that. -- Adam
Re: Re: What DevEnv do you use for Trinidad
And I use Emacs and a command-line, which I imagine makes me very old-school. ;) -- Adam On 12/14/06, Matt Cooper [EMAIL PROTECTED] wrote: Hi Danny, The most common ones I've heard of are either Eclipse or Oracle JDeveloper. I use the latter and create workspace/project files by running the command mvn install jdev:jdev. I believe the expected generated workspace should have 4 projects (api, build, demo, impl) with pre-attached dependencies so you just need to run a jspx page from the demo project and automatically it will build any changes you make in the other projects. Perhaps someone else on this list can better talk to the Eclipse issues you are experiencing. Regards, Matt On 12/14/06, Danny Robinson [EMAIL PROTECTED] wrote: Guys, Are most people using Eclipse to develop the Trinidad components/code? If not, then what do people mainly use? I followed the wiki page that details the Eclipse setup for Trinidad and got a clean compile. However, I'm not certain everything's as it should be, and I certainly can't use the maven eclipse plugin to do a clean 'install'. Using a different approach, 'mvn eclipse:eclipse' command created 4 projects rather than the 2 mentioned in the wiki. However, these wouldn't cleanup compile due to dependencies. Thanks, Danny -- Chordiant Software Inc. www.chordiant.com
Re: Re: Trinidad sandbox?
Of course, this only covers high risk projects that are completely seperable from the main line and don't require modifications there. -- Adam On 12/14/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Right, but high risk projects could be committed to the sandbox first and allow them to ferment a bit without effecting the main line. I like it! +1 (non-binding) Adam Winer wrote: On 12/14/06, Danny Robinson [EMAIL PROTECTED] wrote: +1 (non binding). Q1 - Would this add more workload to those with Commit priviledge, or could we open up the commit access a little more for this project? I don't think there is any process for a less-restrictive commit access for one portion of the product. My understanding is that a committer is a committer is a committer... Someone with more detailed ASF expertise can confirm. -- Adam On 12/14/06, Adam Winer [EMAIL PROTECTED] wrote: I'd like to add a new sandbox project to trinidad, as a parallel directory to trinidad and plugins. This'd give us a place to add more substantial contributions - Danny Robinson's popup, for example - and give them time to be played around with, fixed up, APIs tweaked, etc., before moving in to the main libraries. It'd also give me a chance for committers like me to add experimental features that definitely shouldn't go into the trunk immediately, or perhaps ever (some ideas I've been toying with for multi-component validation, for example). Feedback? +1 from me. ;) -- Adam -- Chordiant Software Inc. www.chordiant.com
Re: [PORTAL] Changes and API review?
Scott, My big concern is with the sheer quantity of new public APIs (that is, public classes in trinidad-api). We should be avoiding making anything public unless it is absolutely, critically necessary. Configurator APIs: I'm not completely sold on the name, but anyway, I think we should: - Make Configurator an abstract class, not an interface. Make most of the methods empty, not abstract. - Add getGlobalConfigurator() to the Configurator API - Eliminate GlobalConfigurator and GenericConfigurator classes TrinidadListener: - *Definitely* should be in impl, not in api. Register it automatically by including it in tr.tld. All of the classes in webapp/wrappers and context/external: - Why aren't these in impl? - I don't understand at all why we could or should be implementing ServletExternalContext... that's provided by the impl. And PortletExternalContext should be provided by the bridge, or the impl as well if it supports portlets. What am I missing? I suspect these come from adding TrinidadFacesContext, so... - TrinidadFacesContext: why can't you just use the regular FacesContextFactory, as we're doing today? Almost any solution is better than duplicating large amounts of impl code. ExternalContextUtils: - To what extent does this really need to be in API? - In particular, I'd rather not expose any of the methods that are getting added to ExternalContext in 1.2: - getRequestCharacterEncoding() - getRequestContentType() ... but in general, I'd rather not expose anything here as a public API unless absolutely necessary. - A Coding surprise: you may not call request.getClass().getMethod(). Doesn't work, sadly, because the defining class might be package-private. You have to get the API directly from ServletRequest.class, PortletRequest.class, etc. On 12/14/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey everyone, As some of you know I have been working on a bunch of enhancements in order to get Trinidad prepared to work on a portal environment. While there is still some myfaces bridge work which needs to be done in order to call this a complete success, I would like to get the work I have done merged into the trunk in order to prevent conflicts and to get everyone working with the new API's. You can find the portal code into the jwaldman-portal branch which has a combination of the following patches as well as some of the work she is working on for skinning. I am going to talk about the Patches corresponding to: ADFFACES-231, ADFFACES-232, ADFFACES-234, and ADFFACES-235. Most importantly, I would like your input on several public API's that were added as a result of this project in order to get approval from the community. Also, as an FYI, I am on the JSR-301 Expert Group and have tried to incorporate a design which will allow us to use that spec once it's finished. The design is still in the preliminary stages, so there is no official support just yet, but I hope to have that support soon after the release of the final draft. Thanks, Scott O'Bryan
Re: Status
What do you mean by working? It's long been working, so do you mean officially released version? -- Adam On 12/13/06, William Hoover [EMAIL PROTECTED] wrote: Do we have an ETA when we will have a working copy of Trinidad? Will Hoover Application Engineer IS - Application Development Nemours Office: (904) 288-5754 Fax:(904) 288-5758 NOTICE...This electronic transmission is intended only for the person(s) named. It may contain information that is (i) proprietary to the sender, and/or (ii) privileged, confidential and/or otherwise exempt from disclosure under applicable State and Federal law, including, but not limited to, privacy standards imposed pursuant to the federal Health Insurance Portability and Accountability Act of 1996 (HIPAA). Receipt by anyone other than the named recipient(s) is not a waiver of any applicable privilege. If you received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message from your system.
Re: [PORTAL] Launch Parameters
This is part of the dialog framework, for returning from a dialog shown in-place (instead of in a popup window). I think it'd be very tough to make this a redirect, since there can be *a lot* of parameters (it's basically a full POST), and they won't all fit in a GET. -- Adam On 12/13/06, Scott O'Bryan [EMAIL PROTECTED] wrote: Hello everyone, I'm looking at supporting launch parameters for the Portal in Trinidad. To recap my understanding of them, in the TrinidadFilter, Trinidad does its filter stuff and then does a doFilter on the FilterChain. When the chain returns, the TrinidadFilter checks for the existence of LaunchParameters and, if they exist, it essentially executes the doFilter again with a modified set of parameters (and thus runs the Lifecycle again). In Portlets we really don't have this capability because this is really controlled by the bridge right now and it is unlikely we'll be able to support this without specific enhancements to the Bridge until JSR-286. So my question is, would I be able to simulate this behavior in a portal environment by sending a redirect back to the portlet with the new parameters? I know that this will cause performance issues in the short term, but it will do so only in a Portal environment and then only until filters are supported in a portal environment. I'm simply not sure how these are used, exactly, which is why I'm asking if the redirect would be functionally equivalent. Scott
Re: Re: PATCH: ServerSide buttons are back
On 12/5/06, Mark Robinson [EMAIL PROTECTED] wrote: Adam, By myfaces.ui, do you mean trinidadinternal.ui? Oops, yes. Is there a reason for getting rid of it? Also, is there migration documentation? Ie, class X is gone, use class Y and Z. It is ancient legacy code - based on UIX - that has to be heavily adapted and twisted to work in a JSF environment. It's slow, arcane, filled with obsolete code paths, etc., etc. Getting rid of it is a major goal in Trinidad. -- Adam Adam Winer wrote: Mark, It's not OK for anything in myfaces.trinidadinternal.renderkit to have dependencies on code in myfaces.ui; our goal is to kill all code in myfaces.ui. So, for example: import org.apache.myfaces.trinidadinternal.ui.UIXRenderingContext; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.IconInputStreamProvider ; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.SimpleDesktopConstants ; import org.apache.myfaces.trinidadinternal.uinode.FacesRenderingContext; ... are all off-limits. (Looking through the patch, it looks as though you've added some other imports unnecessarily.) -- Adam No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.15.9/573 - Release Date: 05/12/2006 4:07 PM
Re: PATCH: ServerSide buttons are back
Mark, It's not OK for anything in myfaces.trinidadinternal.renderkit to have dependencies on code in myfaces.ui; our goal is to kill all code in myfaces.ui. So, for example: import org.apache.myfaces.trinidadinternal.ui.UIXRenderingContext; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.IconInputStreamProvider ; import org.apache.myfaces.trinidadinternal.ui.laf.simple.desktop.SimpleDesktopConstants ; import org.apache.myfaces.trinidadinternal.uinode.FacesRenderingContext; ... are all off-limits. (Looking through the patch, it looks as though you've added some other imports unnecessarily.) -- Adam
Re: Re: GoLinkRenderer calls writeURIAttribute to render name and id, why?
Also? I thought that's exactly what we were talking about.
Were we talking about anything else?
-- Adam
On 11/29/06, Qiang Fan [EMAIL PROTECTED] wrote:
Adam:
Your comment also applies to the following GoLinkRenderer code, right?
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id, clientId, id);
context.getResponseWriter().writeURIAttribute(name, clientId, id);
}
}
Thanks.
John
On 11/29/06, Adam Winer [EMAIL PROTECTED] wrote:
Guys, this is ALWAYS a # URL. It's the name attr of a link, and
can't possibly be anything more. There are zero portal implications.
-- Adam
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Right. Well it's the other cases I'm worried about. I would rather not
have the decision in the Trinidad code whether to encode the URL or
not. We should always be encoding unless we're certain they are
bookmarks. Otherwise, presumably, the app server or portal will handle
it accordingly. Is that not correct?
Scott
Matt Cooper wrote:
If the link's destination starts with # then yes; if the destination
doesn't start with http://;, https://;, mailto:;, javascript: or
anything else.
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
So they will basically reference bookmarks, correct?
Scott
Adam Winer wrote:
Neither; they do not need to be encoded at all, as they
are only references within a page.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
Adam:
I asked the question because I am working on a patch for encoding
URLs in
trinidad. I need to know whether to encode the URL as Action URL
or
Resource
URL.
For the following scenarios I guess they should all be encoded as
Action
URL. But I am not sure. Just want to confirm with you.
In HeaderRenderer (in this case only name is rendered and I did
not
see id
for it):
renderURIAttribute(context, NAME_ATTRIBUTE, label);
And in LinkRenderer:
protected void renderID(
UIXRenderingContext context,
UINode node
) throws IOException
{
Object id = getID(context, node);
if (id != null)
{
if (supportsID(context))
{
// For links, name and thus id is a URI attribute.
renderURIID(context, id);
}
if (supportsNameIdentification(context)
makeNameAndIDSame(context))
{
renderURIAttribute(context, name, id);
}
}
}
Are they all Action URLs?
Thanks.
John
On 11/28/06, Adam Winer [EMAIL PROTECTED] wrote:
The value of the attribute on name on GoLink will end up
mapping
up to href on some other link. So it really is a URI.
E.g., you need to use % encoding, not encoding.
And id must equal name.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
In GoLinkRenderer class, there is the following method:
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id,
clientId,
id);
context.getResponseWriter().writeURIAttribute(name,
clientId,
id);
}
}
Why are id and name rendered as URI? Are the id and name used
as
URI in
javascript logic? I saw some similar code in several other
classes too.
Thanks.
John Fan
Re: GoLinkRenderer calls writeURIAttribute to render name and id, why?
Guys, this is ALWAYS a # URL. It's the name attr of a link, and
can't possibly be anything more. There are zero portal implications.
-- Adam
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
Right. Well it's the other cases I'm worried about. I would rather not
have the decision in the Trinidad code whether to encode the URL or
not. We should always be encoding unless we're certain they are
bookmarks. Otherwise, presumably, the app server or portal will handle
it accordingly. Is that not correct?
Scott
Matt Cooper wrote:
If the link's destination starts with # then yes; if the destination
doesn't start with http://;, https://;, mailto:;, javascript: or
anything else.
On 11/29/06, Scott O'Bryan [EMAIL PROTECTED] wrote:
So they will basically reference bookmarks, correct?
Scott
Adam Winer wrote:
Neither; they do not need to be encoded at all, as they
are only references within a page.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
Adam:
I asked the question because I am working on a patch for encoding
URLs in
trinidad. I need to know whether to encode the URL as Action URL or
Resource
URL.
For the following scenarios I guess they should all be encoded as
Action
URL. But I am not sure. Just want to confirm with you.
In HeaderRenderer (in this case only name is rendered and I did not
see id
for it):
renderURIAttribute(context, NAME_ATTRIBUTE, label);
And in LinkRenderer:
protected void renderID(
UIXRenderingContext context,
UINode node
) throws IOException
{
Object id = getID(context, node);
if (id != null)
{
if (supportsID(context))
{
// For links, name and thus id is a URI attribute.
renderURIID(context, id);
}
if (supportsNameIdentification(context)
makeNameAndIDSame(context))
{
renderURIAttribute(context, name, id);
}
}
}
Are they all Action URLs?
Thanks.
John
On 11/28/06, Adam Winer [EMAIL PROTECTED] wrote:
The value of the attribute on name on GoLink will end up mapping
up to href on some other link. So it really is a URI.
E.g., you need to use % encoding, not encoding.
And id must equal name.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
In GoLinkRenderer class, there is the following method:
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id,
clientId,
id);
context.getResponseWriter().writeURIAttribute(name,
clientId,
id);
}
}
Why are id and name rendered as URI? Are the id and name used as
URI in
javascript logic? I saw some similar code in several other
classes too.
Thanks.
John Fan
Re: GoLinkRenderer calls writeURIAttribute to render name and id, why?
The value of the attribute on name on GoLink will end up mapping
up to href on some other link. So it really is a URI.
E.g., you need to use % encoding, not encoding.
And id must equal name.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
In GoLinkRenderer class, there is the following method:
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id, clientId, id);
context.getResponseWriter().writeURIAttribute(name, clientId, id);
}
}
Why are id and name rendered as URI? Are the id and name used as URI in
javascript logic? I saw some similar code in several other classes too.
Thanks.
John Fan
Re: Re: GoLinkRenderer calls writeURIAttribute to render name and id, why?
Neither; they do not need to be encoded at all, as they
are only references within a page.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
Adam:
I asked the question because I am working on a patch for encoding URLs in
trinidad. I need to know whether to encode the URL as Action URL or Resource
URL.
For the following scenarios I guess they should all be encoded as Action
URL. But I am not sure. Just want to confirm with you.
In HeaderRenderer (in this case only name is rendered and I did not see id
for it):
renderURIAttribute(context, NAME_ATTRIBUTE, label);
And in LinkRenderer:
protected void renderID(
UIXRenderingContext context,
UINode node
) throws IOException
{
Object id = getID(context, node);
if (id != null)
{
if (supportsID(context))
{
// For links, name and thus id is a URI attribute.
renderURIID(context, id);
}
if (supportsNameIdentification(context) makeNameAndIDSame(context))
{
renderURIAttribute(context, name, id);
}
}
}
Are they all Action URLs?
Thanks.
John
On 11/28/06, Adam Winer [EMAIL PROTECTED] wrote:
The value of the attribute on name on GoLink will end up mapping
up to href on some other link. So it really is a URI.
E.g., you need to use % encoding, not encoding.
And id must equal name.
-- Adam
On 11/28/06, Qiang Fan [EMAIL PROTECTED] wrote:
In GoLinkRenderer class, there is the following method:
@Override
protected void renderId(
FacesContext context,
UIComponent component) throws IOException
{
if (shouldRenderId(context, component))
{
String clientId = getClientId(context, component);
// For links, these are actually URI attributes
context.getResponseWriter().writeURIAttribute(id, clientId,
id);
context.getResponseWriter().writeURIAttribute(name, clientId,
id);
}
}
Why are id and name rendered as URI? Are the id and name used as URI in
javascript logic? I saw some similar code in several other classes too.
Thanks.
John Fan
Re: Re: svn commit: r479151 - in /incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces: ./ generator/ generator/component/ generator/t
Bruno,
I'm afraid that I've made things too confusing with the branch
names. The current 1.2 branch isn't the obvious one - it's actually:
https://svn.apache.org/repos/asf/incubator/adffaces/branches/faces-1_2-061113
Sorry about the confusion... could you merge into that branch? I should
really rename the old faces-1_2 branch to something less tempting.
-- Adam
On 11/27/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Ok, I have just merged the development in that branch with the current
12 branch for the plugin. Trinidad seems to build fine for me. It
shouldn't be affected in any way as the changes are mostly to
autogenerate the components for MyFaces.
The branch
https://svn.apache.org/repos/asf/incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin
could be removed now and it shouldn't be used for further development.
Cheers!
Bruno
On 27/11/06, Bruno Aranda [EMAIL PROTECTED] wrote:
Thanks Adam. There is one patch by Andreas Berger that remains to be
applied to the branch. After that, hopefully today, I will test that
trinidad builds well with the branched version and then I will try to
merge it with the current faces 1.2 branch. I agree with you that we
have to avoid a huge code divergence but there were a big amount of
changes, hence the creation of the branch.
Cheers,
Bruno
On 26/11/06, Adam Winer [EMAIL PROTECTED] wrote:
Bruno,
Any idea how/when we're going to merge these changes back?
(Excellent work, by the way!) I'd really like to keep us all
on one branch of the code, instead of getting some huge
code divergence.
-- Adam
On 11/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: baranda
Date: Sat Nov 25 09:41:05 2006
New Revision: 479151
URL: http://svn.apache.org/viewvc?view=revrev=479151
Log:
Applied ADFFACES-303 patch by Andreas Berger
Modified:
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateJspTaglibsMojo.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/ClassGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/GeneratorHelper.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/component/AbstractComponentGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/component/ComponentGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/AbstractComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/ComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/MyFacesComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/TrinidadComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/util/SourceTemplate.java
Modified:
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java?view=diffrev=479151r1=479150r2=479151
==
---
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
(original)
+++
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
Sat Nov 25 09:41:05 2006
@@ -140,8 +140,8 @@
if (componentFamily == null)
{
-getLog().error(Missing component-family for \ +
- fullClassName + \);
+getLog().warn(Missing component-family for \ +
+ fullClassName + \, generation of this Component
is skipped);
}
else
{
@@ -212,7 +212,12 @@
generator.writeFacetMethods(out, component
Re: Problems running Trinidad in Tomcat with file permission restrictions for writing
Craig, IIRC, Trinidad is in fact writing to exactly those temporary directories already, as per the servlet spec. And using our ResourceServlet to pull from those directories. The issue isn't that - it's that GoDaddy is refusing to allow any File writing, even into those legit temporary directories. Which is lame of them. But likely impossible to change. What Trinidad should do is store that .css file into memory, instead of the file system. We used to store a bunch of generated images on the file system, so using memory for all would be quite a pain, but that isn't the case anymore. It'd be a bit slower at startup - when restarting the server, you have to regenerate the file - but for that matter, we have bugs caused by failing to regenerate the .css file in some circumstances. -- Adam -- Adam On 11/20/06, Craig McClanahan [EMAIL PROTECTED] wrote: On 11/16/06, Siarhei Berdachuk [EMAIL PROTECTED] wrote: Hello I have same problems on the my web hosting (Godaddy). There is file permission restrictions for writing from java. I'm build trinidad examples from sources, they works fine on my local host (Windows XP, Tomcat 5.0.28, j2sdk 1.5.0_7) but when I try deploy them to godaddy java enabled Linux hosting (Linux, Tomcat 5.0.27, 1.5.0_06-b05), this examples not works. Hosting server configuration: http://www.lostcd.com/jsp-examples/snp/sysinfo.jsp Then I'm deployd Tomcat jsp examles there and they are works fine: http://www.lostcd.com/jsp-examples/index.html I found article: http://www.oisv.com/articles/web_design/godaddy_gotchas/ where described about some file permission restrictions for writing and possible problem in Log4j. Part from it: In retrospect, this is fairly obvious since all users on the shared server run under the same Java virtual machine instance. Tomcat and Java just do not have the fine-grained ability to assigned directory-based permissions in such as configuration. I cannot see the above article without a login, but *if* GoDaddy is using the Java security manager to enforce restrictions (which certainly makes sense in a shared JVM environment), it is actually possible to be fine grained about file access permissions, but it is pretty tedious. I like trinidad components, but can not use them on my hosting for new projects :( May be somebody have solution for how resolve this problem. I have not looked at the Trinidad source code yet, but one option (if it's not being done already) is for the file writing to be done into a temporary directory that the servlet spec requires be made available (and writable) to each individual webapp. Trinidad can get access to this as follows: FacesContext context = FacesContext.getCurrentInstance(); File tempDirectory = (File) context.getExternalContext ().getApplicationMap().get (javax.servlet.context.tempdir); // tempDirectory is a java.io.File object representing a writable temporary directory // that the webapp can be used to create scratch files It might still take some additional mechanisms to cause this file to ultimately be delivered to the client (since it's not in the webapp's resource space), but this should get the library around file write restrictions. Thank you, Siarhei Berdachuk http://www.berdaflex.com Craig
Re: svn commit: r479151 - in /incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces: ./ generator/ generator/component/ generator/tagli
Bruno,
Any idea how/when we're going to merge these changes back?
(Excellent work, by the way!) I'd really like to keep us all
on one branch of the code, instead of getting some huge
code divergence.
-- Adam
On 11/25/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Author: baranda
Date: Sat Nov 25 09:41:05 2006
New Revision: 479151
URL: http://svn.apache.org/viewvc?view=revrev=479151
Log:
Applied ADFFACES-303 patch by Andreas Berger
Modified:
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateJspTaglibsMojo.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/ClassGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/GeneratorHelper.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/component/AbstractComponentGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/component/ComponentGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/AbstractComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/ComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/MyFacesComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/generator/taglib/TrinidadComponentTagGenerator.java
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/util/SourceTemplate.java
Modified:
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java?view=diffrev=479151r1=479150r2=479151
==
---
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
(original)
+++
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateComponentsMojo.java
Sat Nov 25 09:41:05 2006
@@ -140,8 +140,8 @@
if (componentFamily == null)
{
-getLog().error(Missing component-family for \ +
- fullClassName + \);
+getLog().warn(Missing component-family for \ +
+ fullClassName + \, generation of this Component
is skipped);
}
else
{
@@ -212,7 +212,12 @@
generator.writeFacetMethods(out, component);
-generator.writePropertyMethods(out, component);
+if (template == null)
+{
+ generator.writePropertyMethods(out, component);
+ } else {
+ generator.writePropertyMethods(out, component,
template.getIgnoreMethods());
+ }
if (!suppressListenerMethods)
generator.writeListenerMethods(out, component);
Modified:
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateJspTaglibsMojo.java
URL:
http://svn.apache.org/viewvc/incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateJspTaglibsMojo.java?view=diffrev=479151r1=479150r2=479151
==
---
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateJspTaglibsMojo.java
(original)
+++
incubator/adffaces/branches/myfaces-1_2-maven-faces-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/faces/GenerateJspTaglibsMojo.java
Sat Nov 25 09:41:05 2006
@@ -1468,99 +1468,102 @@
}
}
- class ComponentTagHandlerGenerator
- {
-public void generateTagHandler(
- ComponentBean component)
-{
- String fullClassName = component.getTagClass();
-
-ComponentTagGenerator generator;
-
-if (component.isTrinidadComponent())
-{
-generator = new
