from:"Adam"

Adam Balazs created MYFACES-3886:


 Summary: SerializedViewCollection does not update it's _keys list 
when _serializedViews contains key
 Key: MYFACES-3886
 URL: https://issues.apache.org/jira/browse/MYFACES-3886
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.2
 Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs


When I use DialogFramework (of PrimeFaces), it's adds a new view to the session 
every time. The problem is that when I post an AJAX request to the original 
view, the _keys list is not updated, only the view get updated in the 
_serializedViews map.

After I reach the limit defined with the 
org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the 
first element in the _keys list (which is the container view) - assuming that 
this is the oldest view in the session - and remove the corresponding view from 
the _serializedViews map by the key. But clearly it is not, as I already posted 
some AJAX requests to it.

I think the optimal behavior would be the following: when a view gets an ajax 
request the code should remove the the key from the _keys list and than add it 
as a last element.

The related class is 
org.apache.myfaces.application.viewstate.SerializedViewCollection at the if 
condition started at line 87.

My question is if it is an intended behavior or if it's a bug.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key


[ 
https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978238#comment-13978238
 ] 

Adam Balazs commented on MYFACES-3886:
--

Hi Leonardo,

I've already set this context param to 2.

These are a related context params i have set:

  context-param
param-nameorg.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION/param-name
param-value10/param-value
  /context-param
  context-param

param-nameorg.apache.myfaces.NUMBER_OF_SEQUENTIAL_VIEWS_IN_SESSION/param-name
param-value2/param-value
  /context-param
  context-param
param-nameorg.apache.myfaces.FLASH_SCOPE_DISABLED/param-name
param-valuefalse/param-value
  /context-param
  context-param

param-nameorg.apache.myfaces.USE_FLASH_SCOPE_PURGE_VIEWS_IN_SESSION/param-name
param-valuetrue/param-value
  /context-param

My original issue(not this) has been solved by setting the numbder sequential 
views to 2 (this way the dialog framework won't discard my original view). But 
if I open this dialog frequently (which will generete a new view every time), 
the mentioned issue still exists.

 SerializedViewCollection does not update it's _keys list when 
 _serializedViews contains key
 ---

 Key: MYFACES-3886
 URL: https://issues.apache.org/jira/browse/MYFACES-3886
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.2
 Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs

 When I use DialogFramework (of PrimeFaces), it's adds a new view to the 
 session every time. The problem is that when I post an AJAX request to the 
 original view, the _keys list is not updated, only the view get updated in 
 the _serializedViews map.
 After I reach the limit defined with the 
 org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the 
 first element in the _keys list (which is the container view) - assuming that 
 this is the oldest view in the session - and remove the corresponding view 
 from the _serializedViews map by the key. But clearly it is not, as I already 
 posted some AJAX requests to it.
 I think the optimal behavior would be the following: when a view gets an ajax 
 request the code should remove the the key from the _keys list and than add 
 it as a last element.
 The related class is 
 org.apache.myfaces.application.viewstate.SerializedViewCollection at the if 
 condition started at line 87.
 My question is if it is an intended behavior or if it's a bug.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key


[ 
https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13978313#comment-13978313
 ] 

Adam Balazs commented on MYFACES-3886:
--

I think that is the expected behavior from PF to assign new windowID to every 
opened dialog.
As a fix, I suggest to modify the SerializedViewCollection.java class at the 
line 87 as the followings:

Replace this:
if (_serializedViews.containsKey(key))
{
// Update the state, the viewScopeId does not change.
_serializedViews.put(key, state);
return;
}

By this:

if (_serializedViews.containsKey(key))
{
// Update the state, the viewScopeId does not change.
_serializedViews.put(key, state);
_keys.remove(key);
_keys.add(key);
return;
}

This way the view will be at the end of the list, and the _keys will hold the 
views in 'touching' order. So the _keys[0] will be the oldest view which has 
not been modified.

Patch attached.

 SerializedViewCollection does not update it's _keys list when 
 _serializedViews contains key
 ---

 Key: MYFACES-3886
 URL: https://issues.apache.org/jira/browse/MYFACES-3886
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.2
 Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs
 Attachments: SerializedViewCollection.java.patch


 When I use DialogFramework (of PrimeFaces), it's adds a new view to the 
 session every time. The problem is that when I post an AJAX request to the 
 original view, the _keys list is not updated, only the view get updated in 
 the _serializedViews map.
 After I reach the limit defined with the 
 org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the 
 first element in the _keys list (which is the container view) - assuming that 
 this is the oldest view in the session - and remove the corresponding view 
 from the _serializedViews map by the key. But clearly it is not, as I already 
 posted some AJAX requests to it.
 I think the optimal behavior would be the following: when a view gets an ajax 
 request the code should remove the the key from the _keys list and than add 
 it as a last element.
 The related class is 
 org.apache.myfaces.application.viewstate.SerializedViewCollection at the if 
 condition started at line 87.
 My question is if it is an intended behavior or if it's a bug.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key


 [ 
https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Balazs updated MYFACES-3886:
-

Status: Patch Available  (was: Open)

 SerializedViewCollection does not update it's _keys list when 
 _serializedViews contains key
 ---

 Key: MYFACES-3886
 URL: https://issues.apache.org/jira/browse/MYFACES-3886
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.2
 Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs
 Attachments: SerializedViewCollection.java.patch


 When I use DialogFramework (of PrimeFaces), it's adds a new view to the 
 session every time. The problem is that when I post an AJAX request to the 
 original view, the _keys list is not updated, only the view get updated in 
 the _serializedViews map.
 After I reach the limit defined with the 
 org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the 
 first element in the _keys list (which is the container view) - assuming that 
 this is the oldest view in the session - and remove the corresponding view 
 from the _serializedViews map by the key. But clearly it is not, as I already 
 posted some AJAX requests to it.
 I think the optimal behavior would be the following: when a view gets an ajax 
 request the code should remove the the key from the _keys list and than add 
 it as a last element.
 The related class is 
 org.apache.myfaces.application.viewstate.SerializedViewCollection at the if 
 condition started at line 87.
 My question is if it is an intended behavior or if it's a bug.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key


 [ 
https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Balazs updated MYFACES-3886:
-

Status: Open  (was: Patch Available)

 SerializedViewCollection does not update it's _keys list when 
 _serializedViews contains key
 ---

 Key: MYFACES-3886
 URL: https://issues.apache.org/jira/browse/MYFACES-3886
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.2
 Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs

 When I use DialogFramework (of PrimeFaces), it's adds a new view to the 
 session every time. The problem is that when I post an AJAX request to the 
 original view, the _keys list is not updated, only the view get updated in 
 the _serializedViews map.
 After I reach the limit defined with the 
 org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the 
 first element in the _keys list (which is the container view) - assuming that 
 this is the oldest view in the session - and remove the corresponding view 
 from the _serializedViews map by the key. But clearly it is not, as I already 
 posted some AJAX requests to it.
 I think the optimal behavior would be the following: when a view gets an ajax 
 request the code should remove the the key from the _keys list and than add 
 it as a last element.
 The related class is 
 org.apache.myfaces.application.viewstate.SerializedViewCollection at the if 
 condition started at line 87.
 My question is if it is an intended behavior or if it's a bug.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key


 [ 
https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Balazs updated MYFACES-3886:
-

Status: Patch Available  (was: Open)

 SerializedViewCollection does not update it's _keys list when 
 _serializedViews contains key
 ---

 Key: MYFACES-3886
 URL: https://issues.apache.org/jira/browse/MYFACES-3886
 Project: MyFaces Core
  Issue Type: Bug
  Components: General
Affects Versions: 2.2.2
 Environment: PrimeFaces 4.0.12.
Reporter: Adam Balazs

 When I use DialogFramework (of PrimeFaces), it's adds a new view to the 
 session every time. The problem is that when I post an AJAX request to the 
 original view, the _keys list is not updated, only the view get updated in 
 the _serializedViews map.
 After I reach the limit defined with the 
 org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the 
 first element in the _keys list (which is the container view) - assuming that 
 this is the oldest view in the session - and remove the corresponding view 
 from the _serializedViews map by the key. But clearly it is not, as I already 
 posted some AJAX requests to it.
 I think the optimal behavior would be the following: when a view gets an ajax 
 request the code should remove the the key from the _keys list and than add 
 it as a last element.
 The related class is 
 org.apache.myfaces.application.viewstate.SerializedViewCollection at the if 
 condition started at line 87.
 My question is if it is an intended behavior or if it's a bug.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

tomahawk dynamic tabbedPane

2011-10-13 Thread Adam Furmanczuk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

the tabbedPane in tomahawk is a bit rusty now. I noticed no real
progress recently. In mail archives people complained about tabbedPane
issues years before. And using c:forEach is no good workarround.

I wonder why all tabbedpanes have the inherent inabillity to support
ui:repeat?

I read this post on how to make a tabbed pane [1].

May brilliant idea is: you define in tabbedPane a sepecial tag handler
on what items to group by. say:

t:tabbedPane groupBy=h:panelGroup
ui:repeat value=#{list} var=item
h:panelGroup
h:outputText value=#{item.name}/
/h:panelGroup
/:uirpeat
/:tabbedPane

Now tabbedPane notices: Oh, I have sone h:panelGroups inside next to
each other and i should groupBy panelGroups: ok i make the tabs.. ??

tabbePane knows panelTab can't it be thought to know ui:repeats as well?

Is it difficult to rewrite the tabbedpane to enable ui:repeat?
What would be the steps to make it work?

I tested many alternatives: primefaces:tabView, openfaces:tabset..
Most promising is openfaces:tabbedpane, but cannot make it work properly
somehow..

Thanks for feedback.

Greets,

Adam


[1] =
http://stackoverflow.com/questions/3491969/how-do-i-get-a-tabbed-pane-component-in-jsf-2-0-sun-mojarra
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6Wi0wACgkQefEEI87R1DfFBwCfdqlD9W5vmHsDg6/s5aBgh49b
1A8AnRHYQNe2xTVaAax1/Qgwsxnng6Ok
=g02n
-END PGP SIGNATURE-

Re: [trinidad] cleanup

2011-10-05 Thread Adam Furmanczuk

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Sorry,

I could not resists to comment on Iphone:  deprivation ;)

Greets,

Adam

 Gerhard, by deprivation hints, I'm assuming you mean the javadoc 
 deprecations and not the annotations, right?
 
 Sent from my iPhone
 
 On Oct 5, 2011, at 3:09 AM, Gerhard Petracek
 gerhard.petra...@gmail.com wrote:
 
 hi @ all,
 
 there are still over 400 deprecations (via @Deprecated) and nearly
 400 via javadoc (not all of them overlap). a lot of them are in for a
 long time and some of them were deprecated even before [1].
 
 however, some parts are still used and can't be removed.
 
 imo we should do a cleanup or remove the deprecation hints.
 
 regards, gerhard
 
 [1] https://issues.apache.org/jira/browse/INFRA-1229
 
 http://www.irian.at
 
 Your JSF powerhouse - JSF Consulting, Development and Courses in
 English and German
 
 Professional Support for Apache MyFaces
 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6MMW0ACgkQefEEI87R1DeqNACgguS4nbCFyahxQXJDP4vcpz9D
QcQAniaUrJly4OtaUoczeaOYvf40mD6N
=9b3h
-END PGP SIGNATURE-

Re: HTTP Status 404 [solved] - need help with pom.xml

2011-06-23 Thread Adam Furmanczuk

OK,

It works somehow. From eclipse buid i use primefaces library instead of
tomahawk.. I try to set up my existing project as maven (with a pom.xml)

my project (is like eclipse default)

src/  - java parent package
src/package1
src/package2

WebContent/
WebContent/WEB-INF
WebContent/WEB-INF/lib
WebContent/WEB-INF/classes/log4j.xml
WebContent/.*xhtml
WebContent/resources/
WebContent/resources/js/head.js
WebContent/resources/tmpl/navbar.xhml

now I want to use tomahawk dependecy (added) and let it build.. It
somehow does not include my resources

http://pastebin.com/z8jqWyhd

My Problem probaby here:
[...]
  sourceDirectorysrc/sourceDirectory
resources
  resource
directoryWebContent/directory
  /resource
[..]

THX for you help Leo.

Best Regards,

Adam

Re: HTTP Status 404 [solved] - need help with pom.xml [solved]

2011-06-23 Thread Adam Furmanczuk

Ok, got it working, still my xlmns:t=http://myfaces.apache.org/tomahawk/;

but i recon it out, pomx.xml is all ok.

thx for help from list and irc.

best regards,

Adam

 OK,
 
 It works somehow. From eclipse buid i use primefaces library instead of
 tomahawk.. I try to set up my existing project as maven (with a pom.xml)
 
 my project (is like eclipse default)
 
 src/  - java parent package
 src/package1
 src/package2
 
 WebContent/
 WebContent/WEB-INF
 WebContent/WEB-INF/lib
 WebContent/WEB-INF/classes/log4j.xml
 WebContent/.*xhtml
 WebContent/resources/
 WebContent/resources/js/head.js
 WebContent/resources/tmpl/navbar.xhml
 
 now I want to use tomahawk dependecy (added) and let it build.. It
 somehow does not include my resources
 
 http://pastebin.com/z8jqWyhd
 
 My Problem probaby here:
 [...]
   sourceDirectorysrc/sourceDirectory
 resources
   resource
 directoryWebContent/directory
   /resource
 [..]
 
 THX for you help Leo.
 
 Best Regards,
 
 Adam

HTTP Status 404 _javascriptDetector_

2011-06-22 Thread Adam Furmanczuk

Hi,

I get this error after help from Leonardo, I managed to load all the jars:

myfaces v2, tomahawk1.10, jsp-api.. now should be ok, but I either get
blank page, or 404 _javascriptDetector_

My relevant web.xml part see below. I use url pattern for servlet
mapping and the same pattern for filter mapping
http://myfaces.apache.org/tomahawk/extensionsFilter.html
but eventhough I get Server 500 ExtensionsFilter not correctly
configured (where I use tomahawk taglib) and 404 on pages where i do not
use the tomahawk taglib.

thx for your help folks.

greets,

Adam

web.xml part:

  servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
  /servlet
  servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.jsf/url-pattern
  /servlet-mapping
   filter
filter-nameMyFacesExtensionsFilter/filter-name

filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class
init-param
param-nameuploadMaxFileSize/param-name
param-value20m/param-value
/init-param
/filter
 !-- servlet-name must match the name of your
javax.faces.webapp.FacesServlet entry --
!-- extension mapping for adding script/, link/, and other resource
tags to JSF-pages  --
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name

servlet-nameFaces Servlet/servlet-name
/filter-mapping
!-- extension mapping for serving page-independent resources
(javascript, stylesheets, images, etc.)  --
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
url-pattern*.jsf/url-pattern
/filter-mapping

HTTP Status 404 _javascriptDetector_ -continue

2011-06-22 Thread Adam Furmanczuk

ok

http://myfaces.apache.org/tomahawk/extensionsFilter.html

is ok (- improved settings in web.xml)

when i ask for a site: http:localhost:8080/dir/site.jsf it opens... i
can see it for 1 second and then it disappears and i get the url:
http:localhost:8080/dir/_javascriptDetector_?goto=/dir/site.jsf

So this is some kind of buggy http redirect, but i did no such thing.

Please help.

greets,
Adam
 Hi,
 
 I get this error after help from Leonardo, I managed to load all the jars:
 
 myfaces v2, tomahawk1.10, jsp-api.. now should be ok, but I either get
 blank page, or 404 _javascriptDetector_
 
 My relevant web.xml part see below. I use url pattern for servlet
 mapping and the same pattern for filter mapping
 http://myfaces.apache.org/tomahawk/extensionsFilter.html
 but eventhough I get Server 500 ExtensionsFilter not correctly
 configured (where I use tomahawk taglib) and 404 on pages where i do not
 use the tomahawk taglib.
 
 thx for your help folks.
 
 greets,
 
 Adam
 
 web.xml part:
 
   servlet
 servlet-nameFaces Servlet/servlet-name
 servlet-classjavax.faces.webapp.FacesServlet/servlet-class
 load-on-startup1/load-on-startup
   /servlet
   servlet-mapping
 servlet-nameFaces Servlet/servlet-name
 url-pattern*.jsf/url-pattern
   /servlet-mapping
filter
   filter-nameMyFacesExtensionsFilter/filter-name
   
 filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class
 init-param
 param-nameuploadMaxFileSize/param-name
 param-value20m/param-value
 /init-param
 /filter
  !-- servlet-name must match the name of your
 javax.faces.webapp.FacesServlet entry --
 !-- extension mapping for adding script/, link/, and other resource
 tags to JSF-pages  --
 filter-mapping
 filter-nameMyFacesExtensionsFilter/filter-name
 
 servlet-nameFaces Servlet/servlet-name
 /filter-mapping
 !-- extension mapping for serving page-independent resources
 (javascript, stylesheets, images, etc.)  --
 filter-mapping
 filter-nameMyFacesExtensionsFilter/filter-name
 url-pattern*.jsf/url-pattern
 /filter-mapping

tomahawk 1.1 on apache tomcat 7.0.12 with jsf 2.0

2011-06-20 Thread Adam Furmanczuk

Hi

I am using Apache MyFaces for my project (jsf 2.0) and I want to use the
tomahawk framework (for uploadfile, calendar, etc)

Sadly, Tomcat cancell buidling the war.

When I comment out filter mapping for tomahawk, war gets deployed, but
sided that use:
%@taglib prefix=t uri=http://myfaces.apache.org/tomahawk; %
fail with server 500 error.

when i put filter mapping as suggested

http://myfaces.apache.org/tomahawk/extensionsFilter.html

all fails with SEVERE Filter error.

Please help I need the upload methods urgently for my apache myfaces
webproject.


Best Regards,

Adam
?xml version=1.0 encoding=UTF-8?
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xmlns=http://java.sun.com/xml/ns/javaee; xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; id=WebApp_ID version=2.5
  display-namedocweb/display-name
  session-config
  	session-timeout600/session-timeout
  /session-config
  welcome-file-list
welcome-fileindex.jsf/welcome-file
welcome-fileindex.html/welcome-file
welcome-fileindex.htm/welcome-file
welcome-fileindex.php/welcome-file
welcome-filedefault.html/welcome-file
welcome-filedefault.htm/welcome-file
welcome-filedefault.jsp/welcome-file
  /welcome-file-list
  servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
  /servlet
  servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern*.jsf/url-pattern
  /servlet-mapping
  !--
  filter
	filter-nameMyFacesExtensionsFilter/filter-name
	filter-classorg.apache.myfaces.webapp.filter.ExtensionsFilter/filter-class
init-param
param-nameuploadMaxFileSize/param-name
param-value20m/param-value
/init-param
/filter
--
 !-- servlet-name must match the name of your javax.faces.webapp.FacesServlet entry --
!-- extension mapping for adding script/, link/, and other resource tags to JSF-pages  --
 !--
 filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
   
servlet-nameFaces Servlet/servlet-name
/filter-mapping
--
!-- extension mapping for serving page-independent resources (javascript, stylesheets, images, etc.)  --
!--
filter-mapping
filter-nameMyFacesExtensionsFilter/filter-name
url-pattern*.jsf/url-pattern
/filter-mapping
--
  
  
  context-param
param-namejavax.servlet.jsp.jstl.fmt.localizationContext/param-name
param-valueresources.application/param-value
  /context-param
  context-param
descriptionState saving method: 'client' or 'server' (=default). See JSF Specification 2.5.2/description
param-namejavax.faces.STATE_SAVING_METHOD/param-name
param-valueclient/param-value
  /context-param
  context-param
description
	This parameter tells MyFaces if javascript code should be allowed in
	the rendered HTML output.
	If javascript is allowed, command_link anchors will have javascript code
	that submits the corresponding form.
	If javascript is not allowed, the state saving info and nested parameters
	will be added as url parameters.
	Default is 'true'/description
param-nameorg.apache.myfaces.ALLOW_JAVASCRIPT/param-name
param-valuetrue/param-value
  /context-param
  context-param
description
	If true, rendered HTML code will be formatted, so that it is 'human-readable'
	i.e. additional line separators and whitespace will be written, that do not
	influence the HTML code.
	Default is 'true'/description
param-nameorg.apache.myfaces.PRETTY_HTML/param-name
param-valuetrue/param-value
  /context-param
  context-param
param-nameorg.apache.myfaces.DETECT_JAVASCRIPT/param-name
param-valuetrue/param-value
  /context-param
  context-param
description
	If true, a javascript function will be rendered that is able to restore the
	former vertical scroll on every request. Convenient feature if you have pages
	with long lists and you do not want the browser page to always jump to the top
	if you trigger a link or button action that stays on the same page.
	Default is 'false'
/description
param-nameorg.apache.myfaces.AUTO_SCROLL/param-name
param-valuetrue/param-value
  /context-param
  context-param
	  param-nameorg.ajax4jsf.handleViewExpiredOnClient/param-name
	  param-valuetrue/param-value
	/context-param
	
	
  listener
listener-classorg.apache.myfaces.webapp.StartupServletContextListener/listener-class
  /listener
  error-page
	exception-typejavax.faces.application.ViewExpiredException/exception-type
	location/index.jsp/location
  /error-page
/web-app

Re: tomahawk 1.1 on apache tomcat 7.0.12 with jsf 2.0

2011-06-20 Thread Adam Furmanczuk

THX,

but:

I just deployed one example:

ttp://localhost:8080/myfaces-example-blank-1.1.12-20110601.230445-1/helloWorld.jsf

and i get error code 500.

maybe this error and my webservice error is connected?

Example dies with following error on Tomcat 7.0.12.


See code below.

Best regards,

Adam

java.lang.IllegalArgumentException: Class
org.apache.myfaces.trinidadinternal.application.NavigationHandlerImpl is
no javax.faces.application.NavigationHandler
at
org.apache.myfaces.config.FacesConfigurator.getApplicationObject(FacesConfigurator.java:831)
at
org.apache.myfaces.config.FacesConfigurator.configureApplication(FacesConfigurator.java:753)
at
org.apache.myfaces.config.FacesConfigurator.configure(FacesConfigurator.java:296)
at
org.apache.myfaces.webapp.StartupServletContextListener.initFaces(StartupServletContextListener.java:82)
at
org.apache.myfaces.webapp.StartupServletContextListener.contextInitialized(StartupServletContextListener.java:65)
at
org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4701)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5204)
at
org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5199)
at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)


 Hi
 
 In this address
 
 http://svn.apache.org/repos/asf/myfaces/tomahawk/trunk/examples/
 
 there are some tomahawk examples. Take a look and compare the web.xml.
 
 If you need a working war file, the snapshots can be downloaded from here:
 
 https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/tomahawk/
 
 regards,
 
 Leonardo Uribe
 
 2011/6/20 Adam Furmanczuk afurmanc...@knowtrek.com:
 Hi

 I am using Apache MyFaces for my project (jsf 2.0) and I want to use the
 tomahawk framework (for uploadfile, calendar, etc)

 Sadly, Tomcat cancell buidling the war.

 When I comment out filter mapping for tomahawk, war gets deployed, but
 sided that use:
 %@taglib prefix=t uri=http://myfaces.apache.org/tomahawk; %
 fail with server 500 error.

 when i put filter mapping as suggested

 http://myfaces.apache.org/tomahawk/extensionsFilter.html

 all fails with SEVERE Filter error.

 Please help I need the upload methods urgently for my apache myfaces
 webproject.


 Best Regards,

 Adam

Undocumented (inadvertent?) change in API with 1.2.9 - 1.2.10

2011-04-06 Thread Adam

According to the documentation[1], ApplicationImpl should have a method
called addConverterConfiguration(), however this was removed in 1.2.10.
This can be verified by looking at the source in 1.2.9[2] as compared to
1.2.10[3].

Was this done intentionally? If so, why? Is there a drop in replacement
for this method? Can someone update the documentation to reflect that
this function no longer exists?

If it was unintentional, what is the ETA for the official release of a
corrected version?

[1]
http://myfaces.apache.org/core12/myfaces-impl/apidocs/org/apache/myfaces/application/ApplicationImpl.html
[2]
http://archive.apache.org/dist/myfaces/source/myfaces-core-1.2.9-src.zip
[3]
http://www.apache.org/dyn/closer.cgi/myfaces/source/myfaces-core-assembly-1.2.10-src.zip

Thanks,
Adam

- FHA 203b; 203k; HECM; VA; USDA; Conventional
- Warehouse Lines; FHA-Authorized Originators
- Lending and Servicing in over 45 States
www.swmc.com - www.simplehecmcalculator.com
Visit www.swmc.com/resources for helpful links on Training, Webinars, Lender
Alerts and Submitting Conditions

This email and any content within or attached hereto from Sun West Mortgage
Company, Inc. is confidential and/or legally privileged. The information is
intended only for the use of the individual or entity named on this email. If
you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or taking any action in reliance on the
contents of this email information is strictly prohibited, and that the
documents should be returned to this office immediately by email. Receipt by
anyone other than the intended recipient is not a waiver of any privilege.
Please do not include your social security number, account number, or any other
personal or financial information in the content of the email. Should you have
any questions, please call (800) 453 7884.

[Trinidad] tr:commandbutton issue

2010-10-20 Thread Adam R Rice

I have been trying to use the Trinidad command button to call a method in 
a bean but it doesn't seem to recognise that the method is there.

index.jsp
f:view
html
head
meta http-equiv=Content-Type content=text/html; 
charset=ISO-8859-1
meta content=no-cache http-equiv=Cache-Control /
meta content=no-cache http-equiv=Pragma /
titleTracking/title
/head
body style=height: 100%
tr:form
tr:commandButton action=#{trackingBean.update} /
/tr:form



TrackingBean.java
public String update()
{
// do something;
return ;
}

If I type 'tr:commandButton action=#{trackingBean.' and press Ctrl+Space 
the list of available methods does not show the update() method.

What else do I need to do to allow this method to be selected? I believe 
that the method signature is correct and there is no need to make any 
modifications to faces-config.xml.

Any help would be much appreciated.


Regards,
Adam Rice





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

[jira] Created: (TOMAHAWK-1512) inputHtmlUnicode does not work with firefox 3.6

inputHtmlUnicode does not work with firefox 3.6
---

 Key: TOMAHAWK-1512
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1512
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Html Editor
Affects Versions: 1.1.6, 1.1.7, 1.1.8, 1.1.9
 Environment: win xp, jdk 1.6.0_18, firefox 3.6
Reporter: Adam Faryna
Assignee: Leonardo Uribe
Priority: Critical
 Fix For: 1.1.10-SNAPSHOT


Inserted text gets lost on submitting the form.
There are some JS scricpt errors and it only happens with firefox 3.6 (3.5 or 
IE work fine)

Fehler: Sarissa.getDomDocument is not a function
Quelldatei: 
http://localhost:15281/apps/inf/jsf_demo/faces/extensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12653495/inputHtml.InputHtmlRenderer/kupueditor.js
Zeile: 634

Fehler: setting a property that has only a getter
Quelldatei: 
http://localhost:15281/apps/inf/jsf_demo/faces/extensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12653495/inputHtml.InputHtmlRenderer/sarissa.js
Zeile: 237

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (TOMAHAWK-1512) inputHtmlUnicode does not work with firefox 3.6


[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869079#action_12869079
 ] 

Adam Faryna commented on TOMAHAWK-1512:
---

This bug is similar to TOMAHAWK-1489 but is concerns inputHtmlUnicode.

Error: Sarissa.getDomDocument is not a function
Plik źródłowy: 
http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/kupueditor.js
Wiersz: 634

Error: setting a property that has only a getter
sourcey: 
http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/sarissa.js
Wiersz: 237

 inputHtmlUnicode does not work with firefox 3.6
 ---

 Key: TOMAHAWK-1512
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1512
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Html Editor
Affects Versions: 1.1.6, 1.1.7, 1.1.8, 1.1.9
 Environment: win xp, jdk 1.6.0_18, firefox 3.6
Reporter: Adam Faryna
Assignee: Leonardo Uribe
Priority: Critical
 Fix For: 1.1.10-SNAPSHOT


 Inserted text gets lost on submitting the form.
 There are some JS scricpt errors and it only happens with firefox 3.6 (3.5 or 
 IE work fine)
 Fehler: Sarissa.getDomDocument is not a function
 Quelldatei: 
 http://localhost:15281/apps/inf/jsf_demo/faces/extensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12653495/inputHtml.InputHtmlRenderer/kupueditor.js
 Zeile: 634
 Fehler: setting a property that has only a getter
 Quelldatei: 
 http://localhost:15281/apps/inf/jsf_demo/faces/extensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12653495/inputHtml.InputHtmlRenderer/sarissa.js
 Zeile: 237

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (TOMAHAWK-1512) inputHtmlUnicode does not work with firefox 3.6


[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869079#action_12869079
 ] 

Adam Faryna edited comment on TOMAHAWK-1512 at 5/19/10 6:13 AM:


This bug is similar to TOMAHAWK-1489 but is concerns inputHtmlUnicode.

Error: Sarissa.getDomDocument is not a function
Source: 
http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/kupueditor.js
Row: 634

Error: setting a property that has only a getter
Source: 
http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/sarissa.js
Row: 237

  was (Author: afaryna):
This bug is similar to TOMAHAWK-1489 but is concerns inputHtmlUnicode.

Error: Sarissa.getDomDocument is not a function
Plik źródłowy: 
http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/kupueditor.js
Wiersz: 634

Error: setting a property that has only a getter
sourcey: 
http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/sarissa.js
Wiersz: 237
  
 inputHtmlUnicode does not work with firefox 3.6
 ---

 Key: TOMAHAWK-1512
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1512
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Html Editor
Affects Versions: 1.1.6, 1.1.7, 1.1.8, 1.1.9
 Environment: win xp, jdk 1.6.0_18, firefox 3.6
Reporter: Adam Faryna
Assignee: Leonardo Uribe
Priority: Critical
 Fix For: 1.1.10-SNAPSHOT


 Inserted text gets lost on submitting the form.
 There are some JS scricpt errors and it only happens with firefox 3.6 (3.5 or 
 IE work fine)
 Fehler: Sarissa.getDomDocument is not a function
 Quelldatei: 
 http://localhost:15281/apps/inf/jsf_demo/faces/extensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12653495/inputHtml.InputHtmlRenderer/kupueditor.js
 Zeile: 634
 Fehler: setting a property that has only a getter
 Quelldatei: 
 http://localhost:15281/apps/inf/jsf_demo/faces/extensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12653495/inputHtml.InputHtmlRenderer/sarissa.js
 Zeile: 237

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (TOMAHAWK-1512) inputHtmlUnicode does not work with firefox 3.6


[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12869084#action_12869084
 ] 

Adam Faryna edited comment on TOMAHAWK-1512 at 5/19/10 6:35 AM:


Sorry for mess, this is not Tomahawk issue.

  was (Author: afaryna):
Sorry, this is not Tomcat issue.
  
 inputHtmlUnicode does not work with firefox 3.6
 ---

 Key: TOMAHAWK-1512
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1512
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Html Editor
Affects Versions: 1.1.6, 1.1.7, 1.1.8, 1.1.9, 1.1.10-SNAPSHOT
 Environment: win xp, jdk 1.5.0_14, firefox 3.6, 3.6.3
Reporter: Adam Faryna
Assignee: Leonardo Uribe
Priority: Critical

 This bug is similar to TOMAHAWK-1489  but is concerns inputHtmlUnicode.
 Inserted text gets lost on submitting the form.
 There are some JS scricpt errors and it only happens with firefox 3.6, 3.6.3 
 and probably later.
 Error: Sarissa.getDomDocument is not a function
 Source: 
 http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/kupueditor.js
 Row: 634
 Error: setting a property that has only a getter
 Source: 
 http://localhost:8080/app/faces/myFacesExtensionResource/org.apache.myfaces.renderkit.html.util.MyFacesResourceLoader/12742585/inputHtmlUnicode.InputHtmlUnicodeRenderer/sarissa.js
 Row: 237 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOMAHAWK-1390) t:inputCalendar displays year 1900 when an incorrect date is entered

2009-02-03 Thread Adam Siemion (JIRA)

t:inputCalendar displays year 1900 when an incorrect date is entered


 Key: TOMAHAWK-1390
 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1390
 Project: MyFaces Tomahawk
  Issue Type: Bug
  Components: Calendar
Affects Versions: 1.1.7
Reporter: Adam Siemion
Priority: Minor


When the user provides an incorrect date value (e.g. 12 when the 
popupDateFormat is dd/MM/) the popup will display year 1900 instead of 
the current year.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

MyFaces / Tomahawk / Tiles Blank page

2008-12-28 Thread Adam Nichols

I noticed that TOMAHAWK-922 was supposed to be fixed in MyFaces 1.2.4 
(according to the comments).  I'm using Tiles2, Tomahawk 1.1.8, Tomcat 
6.0.16, and attempting to use MyFaces 1.2.5, however I'm experiencing 
the same problems as previous users; I get a blank page when attempting 
to view any pages.


The reason for this was explained in TOMAHAWK-922, but using 
JspTilesTwoViewHandlerImpl did not help.

https://issues.apache.org/jira/browse/TOMAHAWK-922?focusedCommentId=12583489#action_12583489

My question is this: what needs to be done in order to get 
myfaces-example-tiles to work with MyFaces 1.2?  I thought just dropping 
in the api and core jar files (and removing the old) would be 
sufficient, but it seems this is not the case.


Thanks,
Adam

[jira] Issue Comment Edited: (TOBAGO-657) not running at all

2008-04-28 Thread adam (JIRA)


[ 
https://issues.apache.org/jira/browse/TOBAGO-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592790#action_12592790
 ] 

adamlee edited comment on TOBAGO-657 at 4/28/08 4:38 AM:
--

Thx Bernd Bohmann for ur replay ... I attached all files u will need ... and 
yes I use tomcat 6 as u said.

Thanks  Regards 
Adam

  was (Author: adamlee):
Thx Bernd Bohmann for ur replay ... I attached all files u will need 
  
 not running at all
 --

 Key: TOBAGO-657
 URL: https://issues.apache.org/jira/browse/TOBAGO-657
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: adam
 Attachments: small application.rar


 Hey Guys .. I'm new with Tobago and i make small example to test my knowledge 
 and when i press the button nothing run plz can any one help me and tell me 
 why not running?
 I attached all files that u will need to see it 
 Waiting for ur replay as soon as possible
 plz any one help me on my first application 
 faces-config.xml:
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE faces-config PUBLIC
 -//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN
 http://java.sun.com/dtd/web-facesconfig_1_1.dtd;
 faces-config
   managed-bean
   managed-bean-name
   goClass/managed-bean-name
   managed-bean-class
   com.GoClass/managed-bean-class
   managed-bean-scope
   session/managed-bean-scope
   /managed-bean
   navigation-rule
   display-name
   index/display-name
   from-view-id
   /index.jsp/from-view-id
   navigation-case
   from-outcomesuccess/from-outcome
   to-view-id
   /success.jsp/to-view-id
   /navigation-case
   /navigation-rule
 /faces-config
 tobago-config.xml : 
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE tobago-config PUBLIC
 -//The Apache Software Foundation//DTD Tobago Config 1.0//EN 
 tobago-config_1_0.dtd
 tobago-config
   theme-config
 default-themespeyside/default-theme
 supported-themescarborough/supported-theme
 supported-themerichmond/supported-theme
 supported-themecharlotteville/supported-theme
   /theme-config
   resource-dirtobago-resource/resource-dir
   ajax-enabledtrue/ajax-enabled
 /tobago-config
 web.xml : 
 ?xml version=1.0 encoding=UTF-8?
 web-app id=WebApp_ID version=2.4
   xmlns=http://java.sun.com/xml/ns/j2ee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee 
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
   display-nameTestJSF/display-name
   !-- add filter to tobago facet --
   filter
   filter-namemultipartFormdataFilter/filter-name
   filter-class
   
 org.apache.myfaces.tobago.webapp.TobagoMultipartFormdataFilter
   /filter-class
   init-param
   description
   Set the size limit for uploaded files. Default 
 value is
   1 MB. Format: 10 = 10 bytes 10k = 10 KB 10m = 
 10 MB 1g =
   1 GB
   /description
   param-nameuploadMaxFileSize/param-name
   param-value20m/param-value
   /init-param
   !--init-param
   descriptionSet the upload repository path for 
 uploaded files. Default value is java.io.tmpdir./description
   param-nameuploadRepositoryPath/param-name
   param-value/tmp/param-value
   /init-param--
   /filter
   filter-mapping
   filter-namemultipartFormdataFilter/filter-name
   url-pattern/faces/*/url-pattern
   /filter-mapping
   !-- add listener to tobago facet --
   listener
   listener-class
   
 org.apache.myfaces.tobago.webapp.TobagoServletContextListener
   /listener-class
   /listener
   servlet
   servlet-nameFaces Servlet/servlet-name
   servlet-classjavax.faces.webapp.FacesServlet/servlet-class
   load-on-startup1/load-on-startup
   /servlet
   servlet-mapping
   servlet-nameFaces Servlet/servlet-name
   url-pattern/faces/*/url-pattern
   /servlet-mapping
   welcome-file-list
   welcome-fileindex.html/welcome-file
   welcome-fileindex.htm/welcome-file
   welcome-fileindex.jsp/welcome-file
   welcome-filedefault.html/welcome-file
   welcome-filedefault.htm/welcome-file
   welcome-filedefault.jsp/welcome-file
   /welcome-file-list
 /web-app
 index.jsp

[jira] Issue Comment Edited: (TOBAGO-657) not running at all

2008-04-28 Thread adam (JIRA)


[ 
https://issues.apache.org/jira/browse/TOBAGO-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12592790#action_12592790
 ] 

adamlee edited comment on TOBAGO-657 at 4/28/08 4:37 AM:
--

Thx Bernd Bohmann for ur replay ... I attached all files u will need 

  was (Author: adamlee):
all files u will need it 
  
 not running at all
 --

 Key: TOBAGO-657
 URL: https://issues.apache.org/jira/browse/TOBAGO-657
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: adam
 Attachments: small application.rar


 Hey Guys .. I'm new with Tobago and i make small example to test my knowledge 
 and when i press the button nothing run plz can any one help me and tell me 
 why not running?
 I attached all files that u will need to see it 
 Waiting for ur replay as soon as possible
 plz any one help me on my first application 
 faces-config.xml:
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE faces-config PUBLIC
 -//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN
 http://java.sun.com/dtd/web-facesconfig_1_1.dtd;
 faces-config
   managed-bean
   managed-bean-name
   goClass/managed-bean-name
   managed-bean-class
   com.GoClass/managed-bean-class
   managed-bean-scope
   session/managed-bean-scope
   /managed-bean
   navigation-rule
   display-name
   index/display-name
   from-view-id
   /index.jsp/from-view-id
   navigation-case
   from-outcomesuccess/from-outcome
   to-view-id
   /success.jsp/to-view-id
   /navigation-case
   /navigation-rule
 /faces-config
 tobago-config.xml : 
 ?xml version=1.0 encoding=UTF-8?
 !DOCTYPE tobago-config PUBLIC
 -//The Apache Software Foundation//DTD Tobago Config 1.0//EN 
 tobago-config_1_0.dtd
 tobago-config
   theme-config
 default-themespeyside/default-theme
 supported-themescarborough/supported-theme
 supported-themerichmond/supported-theme
 supported-themecharlotteville/supported-theme
   /theme-config
   resource-dirtobago-resource/resource-dir
   ajax-enabledtrue/ajax-enabled
 /tobago-config
 web.xml : 
 ?xml version=1.0 encoding=UTF-8?
 web-app id=WebApp_ID version=2.4
   xmlns=http://java.sun.com/xml/ns/j2ee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee 
 http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
   display-nameTestJSF/display-name
   !-- add filter to tobago facet --
   filter
   filter-namemultipartFormdataFilter/filter-name
   filter-class
   
 org.apache.myfaces.tobago.webapp.TobagoMultipartFormdataFilter
   /filter-class
   init-param
   description
   Set the size limit for uploaded files. Default 
 value is
   1 MB. Format: 10 = 10 bytes 10k = 10 KB 10m = 
 10 MB 1g =
   1 GB
   /description
   param-nameuploadMaxFileSize/param-name
   param-value20m/param-value
   /init-param
   !--init-param
   descriptionSet the upload repository path for 
 uploaded files. Default value is java.io.tmpdir./description
   param-nameuploadRepositoryPath/param-name
   param-value/tmp/param-value
   /init-param--
   /filter
   filter-mapping
   filter-namemultipartFormdataFilter/filter-name
   url-pattern/faces/*/url-pattern
   /filter-mapping
   !-- add listener to tobago facet --
   listener
   listener-class
   
 org.apache.myfaces.tobago.webapp.TobagoServletContextListener
   /listener-class
   /listener
   servlet
   servlet-nameFaces Servlet/servlet-name
   servlet-classjavax.faces.webapp.FacesServlet/servlet-class
   load-on-startup1/load-on-startup
   /servlet
   servlet-mapping
   servlet-nameFaces Servlet/servlet-name
   url-pattern/faces/*/url-pattern
   /servlet-mapping
   welcome-file-list
   welcome-fileindex.html/welcome-file
   welcome-fileindex.htm/welcome-file
   welcome-fileindex.jsp/welcome-file
   welcome-filedefault.html/welcome-file
   welcome-filedefault.htm/welcome-file
   welcome-filedefault.jsp/welcome-file
   /welcome-file-list
 /web-app
 index.jsp: 
 %@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
 %@ taglib uri=http://java.sun.com/jsf/html; prefix

[jira] Created: (TOBAGO-657) not running at all

2008-04-27 Thread adam (JIRA)

not running at all
--

 Key: TOBAGO-657
 URL: https://issues.apache.org/jira/browse/TOBAGO-657
 Project: MyFaces Tobago
  Issue Type: Bug
Reporter: adam


Hey Guys .. I'm new with Tobago and i make small example to test my knowledge 
and when i press the button nothing run plz can any one help me and tell me why 
not running?
I attached all files that u will need to see it 

Waiting for ur replay as soon as possible

plz any one help me on my first application 


faces-config.xml:
?xml version=1.0 encoding=UTF-8?

!DOCTYPE faces-config PUBLIC
-//Sun Microsystems, Inc.//DTD JavaServer Faces Config 1.1//EN
http://java.sun.com/dtd/web-facesconfig_1_1.dtd;

faces-config
managed-bean
managed-bean-name
goClass/managed-bean-name
managed-bean-class
com.GoClass/managed-bean-class
managed-bean-scope
session/managed-bean-scope
/managed-bean
navigation-rule
display-name
index/display-name
from-view-id
/index.jsp/from-view-id
navigation-case
from-outcomesuccess/from-outcome
to-view-id
/success.jsp/to-view-id
/navigation-case
/navigation-rule

/faces-config





tobago-config.xml : 

?xml version=1.0 encoding=UTF-8?

!DOCTYPE tobago-config PUBLIC
-//The Apache Software Foundation//DTD Tobago Config 1.0//EN 
tobago-config_1_0.dtd

tobago-config

  theme-config
default-themespeyside/default-theme
supported-themescarborough/supported-theme
supported-themerichmond/supported-theme
supported-themecharlotteville/supported-theme
  /theme-config

  resource-dirtobago-resource/resource-dir
  ajax-enabledtrue/ajax-enabled
/tobago-config



web.xml : 

?xml version=1.0 encoding=UTF-8?
web-app id=WebApp_ID version=2.4
xmlns=http://java.sun.com/xml/ns/j2ee;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://java.sun.com/xml/ns/j2ee 
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd;
display-nameTestJSF/display-name
!-- add filter to tobago facet --
filter
filter-namemultipartFormdataFilter/filter-name
filter-class

org.apache.myfaces.tobago.webapp.TobagoMultipartFormdataFilter
/filter-class
init-param
description
Set the size limit for uploaded files. Default 
value is
1 MB. Format: 10 = 10 bytes 10k = 10 KB 10m = 
10 MB 1g =
1 GB
/description
param-nameuploadMaxFileSize/param-name
param-value20m/param-value


/init-param
!--init-param
descriptionSet the upload repository path for 
uploaded files. Default value is java.io.tmpdir./description
param-nameuploadRepositoryPath/param-name
param-value/tmp/param-value
/init-param--
/filter
filter-mapping
filter-namemultipartFormdataFilter/filter-name
url-pattern/faces/*/url-pattern
/filter-mapping
!-- add listener to tobago facet --
listener
listener-class

org.apache.myfaces.tobago.webapp.TobagoServletContextListener
/listener-class
/listener
servlet
servlet-nameFaces Servlet/servlet-name
servlet-classjavax.faces.webapp.FacesServlet/servlet-class
load-on-startup1/load-on-startup
/servlet
servlet-mapping
servlet-nameFaces Servlet/servlet-name
url-pattern/faces/*/url-pattern
/servlet-mapping
welcome-file-list
welcome-fileindex.html/welcome-file
welcome-fileindex.htm/welcome-file
welcome-fileindex.jsp/welcome-file
welcome-filedefault.html/welcome-file
welcome-filedefault.htm/welcome-file
welcome-filedefault.jsp/welcome-file
/welcome-file-list
/web-app

index.jsp: 
%@ taglib uri=http://java.sun.com/jsf/core; prefix=f%
%@ taglib uri=http://java.sun.com/jsf/html; prefix=h%
%@ taglib uri=http://myfaces.apache.org/tobago/component; prefix=tc%
%@ taglib uri=http://myfaces.apache.org/tobago/extension; prefix=tx%

f:view
tc:page
tc:panel
f:facet name=layout
tc:gridLayout rows=fixed;* /
/f:facet
tc:button label=Enter Here 
action=#{goClass.go}/tc:button

[jira] Commented: (TRINIDAD-773) Inefficient way to create faces ben in FacesBeanFactory

2007-11-24 Thread Adam Winer (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545187
 ] 

Adam Winer commented on TRINIDAD-773:
-

At a quick glance, this checkin has a big thread-safety problem:  
FacesBeanFactory can be called from multiple threads, but you're using a 
non-threadsafe data structure.

Switch that HashMap to a ConcurrentHashMap and it'll be safe.

 Inefficient way to create faces ben in FacesBeanFactory
 ---

 Key: TRINIDAD-773
 URL: https://issues.apache.org/jira/browse/TRINIDAD-773
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Stevan Malesevic
Assignee: Jeanne Waldman
 Fix For: 1.0.5-core


 It seems that the way FacesBeanFactory::createFacesBean creates faces bean is 
 were inefficient. The problem is that for the case where we have deep 
 subclass structure and root class defines the bean we will make a numerouse 
 calls to createFacesBean before we find out the type for the bean. This will 
 burn the CPU and use memory to create all the keys. One possible optimization 
 might be to create a map between ownerClass|rendererType and calss for the 
 bean at the top level where the createFacesBean is called. So, next call will 
 find it right away. I played with the dirty prototype for this and I was able 
 to see memory improvement of about 140K per request (I have not measure CPU 
 improvement).
 The prototype I had looked like (were dirty but it works):
 /*
  *  Licensed to the Apache Software Foundation (ASF) under one
  *  or more contributor license agreements.  See the NOTICE file
  *  distributed with this work for additional information
  *  regarding copyright ownership.  The ASF licenses this file
  *  to you under the Apache License, Version 2.0 (the
  *  License); you may not use this file except in compliance
  *  with the License.  You may obtain a copy of the License at
  * 
  *  http://www.apache.org/licenses/LICENSE-2.0
  * 
  *  Unless required by applicable law or agreed to in writing,
  *  software distributed under the License is distributed on an
  *  AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  *  KIND, either express or implied.  See the License for the
  *  specific language governing permissions and limitations
  *  under the License.
  */
 package org.apache.myfaces.trinidad.bean;
 import java.io.InputStream;
 import java.io.IOException;
 import java.net.URL;
 import java.util.ArrayList;
 import java.util.Collections;
 import java.util.Enumeration;
 import java.util.HashMap;
 import java.util.List;
 import java.util.Map;
 import java.util.Properties;
 import org.apache.myfaces.trinidad.logging.TrinidadLogger;
 /**
  * Base interface for FacesBean storage.
  *
  */
 public class FacesBeanFactory
 {
   /**
* Create a FacesBean for a component class.
*/
   // TODO change from ownerClass to componentFamily?
   static public FacesBean createFacesBean(
 Class? ownerClass,
 String   rendererType)
   {
 if (ownerClass == null)
   return null;
 String className = ownerClass.getName();
 FacesBean bean = createFacesBean(className, rendererType);
 if (bean == null  rendererType != null)
 {
   bean = createFacesBean(className, null);
   
   if(bean != null)
   {
 String typeKey = (rendererType != null)
 ? new 
 StringBuilder(className).append(|).append(rendererType).toString()
 : className;
 _TYPES_CLASS.put(typeKey, bean.getClass());
   }
 }
 
 if (bean == null)
 {
   bean = createFacesBean(ownerClass.getSuperclass(), rendererType);
   
   if(bean != null)
   {
 String typeKey = (rendererType != null)
 ? new 
 StringBuilder(className).append(|).append(rendererType).toString()
 : className;
 _TYPES_CLASS.put(typeKey, bean.getClass());
   }
 }
 return bean;
   }
   static public FacesBean createFacesBean(
 String beanType,
 String rendererType)
   {
 String typeKey = (rendererType != null)
 ? new 
 StringBuilder(beanType).append(|).append(rendererType).toString()
 : beanType;
 
 Class? type = _TYPES_CLASS.get(typeKey);
   
 if(type == null)
 {
   String className = (String) _TYPES_MAP.get(typeKey);
   if (className == null)
 return null;
   
   try
   {
 type = _getClassLoader().loadClass(className);
 _TYPES_CLASS.put(typeKey, type);
   }
   catch (ClassNotFoundException cnfe)
   {
 _LOG.severe(CANNOT_FIND_FACESBEAN, className);
 _LOG.severe(cnfe);
   }
 }
   
 try
 {
   return (FacesBean) type.newInstance

[jira] Commented: (MYFACES-384) Allow Pre-compiling web application for Tomcat

2007-11-22 Thread Adam Jenkins (JIRA)


[ 
https://issues.apache.org/jira/browse/MYFACES-384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12544890
 ] 

Adam Jenkins commented on MYFACES-384:
--

What's the status of this issue.  It seems there was a solution supplied quite 
some time ago, did it ever make it into any builds?

Cheers
Adam

 Allow Pre-compiling web application for Tomcat
 --

 Key: MYFACES-384
 URL: https://issues.apache.org/jira/browse/MYFACES-384
 Project: MyFaces Core
  Issue Type: Improvement
  Components: General
Affects Versions: 1.0.9m9
 Environment: Tomcat -- Jasper2
Reporter: John Schneider
Assignee: Manfred Geiler
Priority: Minor

 Pre-compiling web applications for Tomcat is not supported out of the box 
 as it should be.  I have written a filter that performs essentially the same 
 function as FacesServlet, so that each individual JSP servlet can be defined 
 and mapped in web.xml.  However, limitations in 
 myfaces.webapp.webxml.WebXml.getFacesServletMappings() prevents these mapped 
 servlets from rendering the view. 
 The code in question is: if 
 (FacesServlet.class.isAssignableFrom(servletClass)) {
 This will prevent any pre-compiled page from being added as a faces servlet 
 mapping, as these servlets extend org.apache.jasper.runtime.HttpJspBase.
 The applicable stack trace is as follows:
 14:02:45,443 DEBUG LifecycleImpl:118 - entering restoreView in 
 org.apache.myfaces
 .lifecycle.LifecycleImpl
 14:02:45,637 DEBUG JspStateManagerImpl:196 - No serialized view found in 
 server s
 ession!
 14:02:45,779 DEBUG JspViewHandlerImpl:191 - Created view /success.jsp
 14:02:45,914 DEBUG DebugUtils:158 - Newly created view
 
 UIViewRoot id=NULL family=javax.faces.ViewRoot locale=en 
 renderKitId=HTML
 _BASIC rendered=true rendererType=NULL rendersChildren=false 
 transient=fa
 lse viewId=/success.jsp/
 
 14:02:45,960 DEBUG LifecycleImpl:157 - exiting restoreView in 
 org.apache.myfaces.
 lifecycle.LifecycleImpl (-- render response)
 14:02:45,963 DEBUG LifecycleImpl:288 - entering renderResponse in 
 org.apache.myfa
 ces.lifecycle.LifecycleImpl
 14:02:45,981 DEBUG WebXmlParser:117 - ignoring servlet + 
 org.apache.jsp.success_j
 sp class org.apache.jsp.success_jsp (no FacesServlet)
 14:02:45,985 ERROR JspViewHandlerImpl:424 - no faces servlet mappings found
 14:02:46,012 ERROR success_jsp]:253 - Servlet.service() for servlet 
 org.apache.js
 p.success_jsp threw exception
 java.lang.IllegalArgumentException: could not find pathMapping for 
 servletPath =
 /success.jsf requestPathInfo = null
 at 
 org.apache.myfaces.application.jsp.JspViewHandlerImpl.getServletMappin
 g(JspViewHandlerImpl.java:425)
 at 
 org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspVi
 ewHandlerImpl.java:246)
 at 
 org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:3
 00)
 at com.urban4life.web.util.FacesFilter.doFilter(FacesFilter.java:63)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appli
 cationFilterChain.java:202)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFi
 lterChain.java:173)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperVa
 lve.java:213)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextVa
 lve.java:178)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.ja
 va:126)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.ja
 va:105)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValv
 e.java:107)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java
 :148)
 at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:
 856)
 at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.proces
 sConnection(Http11Protocol.java:744)
 at 
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoi
 nt.java:527)
 at 
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFoll
 owerWorkerThread.java:80)
 at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPo
 ol.java:684)
 at java.lang.Thread.run(Thread.java:595)
 -
 FacesFilter:
 import java.io.IOException;
 import javax.faces.FactoryFinder;
 import javax.faces.context.FacesContext;
 import javax.faces.context.FacesContextFactory;
 import javax.faces.lifecycle.Lifecycle;
 import javax.faces.lifecycle.LifecycleFactory;
 import javax.servlet.Filter;
 import javax.servlet.FilterChain;
 import javax.servlet.FilterConfig;
 import

Re: [Trinidad] Dialog - DialogRequest.java

2007-11-05 Thread Adam Winer

Sounds like the right thing to do.

-- Adam


On 11/4/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 ok, no complains, here

 On 10/30/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi Mario,
 
  yes, but since this isn't there since a long time, I am asking.
  Orchestra is really nice :-)
 
  -M
 
 
  On 10/30/07, Mario Ivankovits [EMAIL PROTECTED] wrote:
   Hi Matthias!
but Orchestra expects a conversationContext param in that URL, like
/__ADFv__.xhtml?_afPfm=5c4a2651_t=fred_vir=/gmap/map.xhtmlloc=enconversationContext=1
   
Doing this as well:
context.getExternalContext().encodeActionURL(theUrlWeCreated);
   
   I don't know anything about Trinidad, but I am pretty sure it is save to
   add this encoding, else, the windowing stuff will fail with cookies-only
   environments as then the ;jsessionid= is missing too.
  
   Ciao,
   Mario
  
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

[jira] Updated: (TRINIDAD-713) Using name as the id for a component breaks form submission. name appears to be an undocumented reserved identifier.

2007-10-13 Thread Adam Winer (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer updated TRINIDAD-713:


   Resolution: Fixed
Fix Version/s: 1.0.4-core
 Assignee: Adam Winer
   Status: Resolved  (was: Patch Available)

 Using name as the id for a component breaks form submission. name appears 
 to be an undocumented reserved identifier.
 

 Key: TRINIDAD-713
 URL: https://issues.apache.org/jira/browse/TRINIDAD-713
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.2-core
Reporter: Mike Hanafey
Assignee: Adam Winer
 Fix For: 1.0.4-core

 Attachments: patchInvalidIdNameComponent.patch


  Using the trinidad-blank as an example, if the the id of the input field in 
 page1.jspx is changed from:
  tr:inputText label=Your name id=input1 
 value=#{helloWorldBacking.name} required=true/
 to:
  tr:inputText label=Your name id=name 
 value=#{helloWorldBacking.name} required=true/
 nothing happens when the press me button is pushed (the form is not posted).
 The following JavaScript error is reported:
 Error ``TypeError: a0.split is not a function'' [xs] in file 
 ``http://localhost:8080/trinidad/adf/jsLibs/Common1_2_2.js'', line 4512, 
 character 0.
 In the code fragment below a0 has been resolved to the HTMLFormElement, but 
 apparently because the form contains a button element named name, a0.name 
 does not return the form name, but instead the button instance, and split 
 is not a method on HTMLButtonElement.
 4861 if(!a0)
 4862 return false;
 4863 var a6=window[_+_getJavascriptId(a0.name)+Validator];
 4864 if(a6==(void 0))
   function _getJavascriptId(a0)
4511 {
4512 return a0.split(':').join('_');
4513 }
 Is there a way in JavaScript to avoid this name conflict? It does not seem 
 reasonable it is illegal to add an element called name to a form.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-756) Event delivery phases get overwritten

2007-10-13 Thread Adam Winer (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer updated TRINIDAD-756:


   Resolution: Fixed
Fix Version/s: 1.2.4-plugins
   Status: Resolved  (was: Patch Available)

 Event delivery phases get overwritten
 -

 Key: TRINIDAD-756
 URL: https://issues.apache.org/jira/browse/TRINIDAD-756
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Build
Affects Versions:  1.2.2-plugins,  1.2.3-plugins
Reporter: Bud Osterberg
 Fix For: 1.2.4-plugins

 Attachments: phases.patch


 The description for a lot of events looks something like this:
   mfp:event
 
 mfp:event-typeorg.apache.myfaces.trinidad.AttributeChange/mfp:event-type
 mfp:event-delivery-phaseInvoke 
 Application/mfp:event-delivery-phase
 mfp:event-delivery-phaseApply Request 
 Values/mfp:event-delivery-phase
   /mfp:event
 However, the setEventDeliveryPhases method just assigns the input array to 
 _deliveryPhases. This results in the tagdoc only listing the last phase 
 (Apply Request Values in the example above).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] Patches! Fresh patches! Patches anybody?

2007-10-13 Thread Adam Winer

Hey, Stephen, a couple of comments:
- The patch for 755 includes a lot of changes that aren't specific to
  your work (removing unnecessary imports, whitespace adjustments, etc.)
  If you want to create separate, minor issues of Unnecessary imports,
  and attach a separate patch there, that's cool.
- It's really good to have some discussions over the APIs, instead of
  asking for patches to be checked in as is.
- Looking at the patch, it seems as though you're using properties
  including af|outputLabel;  yet the skin selector doc just referred to
  -tr-required-icon-position.  I think this is a skinning property that is
  not at all specific to outputLabel, so the doc is right, the code wrong.

-- Adam


On 10/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
 What is the best way to contribute to Trinidad?
 I went ahead and supplied two patches for issues I was having with missing 
 skinning features: TRINIDAD-755, TRINIDAD-745

 Right now, I am missing another feature (putting labels _above_ fields).
 I am a little hesitant to supply yet another patch while I haven't heard 
 anything on my older patches.

 Can a committer please have a look at my previous patches and comment on 
 them? I am willing to put some more work into them if you see any flaws, but 
 it would be great if in the end the features would make it into the code base.

 Thanks a lot!

[jira] Resolved: (TRINIDAD-754) NullPointerException if inputText in table is required in 1.2.2 branch

2007-10-11 Thread Adam Winer (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer resolved TRINIDAD-754.
-

   Resolution: Fixed
Fix Version/s: 1.2.3-core
 Assignee: Adam Winer

Fixed in the real 1.2.3 branch.

 NullPointerException if inputText in table is required in 1.2.2 branch
 --

 Key: TRINIDAD-754
 URL: https://issues.apache.org/jira/browse/TRINIDAD-754
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Jeanne Waldman
Assignee: Adam Winer
 Fix For: 1.2.3-core


 This bug only reproduces in the 1.2.2 branch, not in the 1.0.3 branch.
 Open the table.jspx page in the trinidad-demo to edit it.
 Change the second table's inputText to be required:
 tr:inputText value=#{row.symbol}  
 shortDesc=#{row.symbol} required=true/
 Run the demo page.
 Clear one of the row's inputText that you made required.
 Submit.
 You will get the following NPE:
 java.lang.NullPointerException
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderMessageAnchor(MessageBoxRenderer.java:295)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderComponentMessages(MessageBoxRenderer.java:253)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer._renderContent(MessageBoxRenderer.java:194)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer$BoxRenderer.renderBody(MessageBoxRenderer.java:443)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer._renderMiddleRow(PanelBoxRenderer.java:267)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelBoxRenderer.encodeAll(PanelBoxRenderer.java:115)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.MessageBoxRenderer.encodeAll(MessageBoxRenderer.java:135)
 at 
 org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:220)
 at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:749)
 at 
 org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:69)
 at 
 org.apache.myfaces.trinidad.render.CoreRenderer.encodeChild(CoreRenderer.java:294)
 at 
 org.apache.myfaces.trinidad.render.CoreRenderer.encodeAllChildren(CoreRenderer.java:316)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.renderContent(PanelPartialRootRenderer.java:64)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.renderContent(BodyRenderer.java:139)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPartialRootRenderer.encodeAll(PanelPartialRootRenderer.java:119)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.BodyRenderer.encodeAll(BodyRenderer.java:79)
 at 
 org.apache.myfaces.trinidad.render.CoreRenderer.delegateRenderer(CoreRenderer.java:330)
 at 
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.DocumentRenderer.encodeAll(DocumentRenderer.java:80)
 at 
 org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:220)
 at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:749)
 at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.__encodeRecursive(UIXComponentBase.java:1287)
 at 
 org.apache.myfaces.trinidad.component.UIXComponentBase.encodeAll(UIXComponentBase.java:769)
 at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
 at 
 com.sun.faces.application.ViewHandlerImpl.doRenderView(ViewHandlerImpl.java:244)
 at 
 com.sun.faces.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175)
 at 
 javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:178)
 at 
 org.apache.myfaces.trinidadinternal.application.ViewHandlerImpl.renderView(ViewHandlerImpl.java:175)
 at 
 com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:106)
 at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:251)
 at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0) 
 ].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
 at 
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._invokeDoFilter(TrinidadFilterImpl.java:241)
 at 
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:198)
 at 
 org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:141)
 at 
 org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
 at com.evermind[Oracle Containers for J2EE 10g (11.1.1.0.0

Re: [Trinidad] please comment on the following bug

2007-10-08 Thread Adam Winer

On 10/8/07, Andrew Robinson [EMAIL PROTECTED] wrote:
  My recommendation is to change the code and documentation to:
   - If the component is a naming container, search relative to the
 parent;  otherwise search relative to the component

 But what if the person does want to search the children? If the parent
 was used, they would have to refer to themselves, which is more
 confusing IMO.

I agree, that's confusing.  But, IMO, I think that requiring
:: for finding peers:

  af:commandLink id=foo .../
  af:table partialTriggers=::foo.../af:table

is also really confusing, and suspect that searching for
peers is much more common than searching for children.  Plus,
it's existing behavior, and breaking existing behavior is never
a good thing.

-- Adam


 Example:

 my:namingContainer partialTriggers=link
 tr:commandLink id=link partialSubmit=true /
 /my:namingContainer

 versus:

 my:namingContainer id=nc partialTriggers=nc:link
 tr:commandLink id=link partialSubmit=true /
 /my:namingContainer

 So, if it was left as-is in terms of documentation, the following
 would be the correct way to refer to a child and refer to a sibling:

 tr:commandLink id=outsideLink /
 my:namingContainer partialTriggers=link, ::outsideLink
 tr:commandLink id=link partialSubmit=true /
 /my:namingContainer

 That seems to make sense to me at least

 -Andrew

Re: [Trinidad] navigationTree not refactored???

2007-10-08 Thread Adam Winer

It's desperately in need of refactoring to extend off of
the new TreeRenderer, and not the old 'uix' one.

-- Adam


On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote:
 Hi all!

 I need I really need the navigationTree and I noticed the renderer is still
 in the 'uix' package
 and that the code is... still old style and I don't understand nothing.
 It's extremely short and I didn't figure it out where's all the rendering
 implemented.

 Can somebody help me with some hints?
 I would like to refactor it and enhance its skinning (which for now seems to
 be disabled)

 --
 Cristi Toth

 -
 Codebeat
  www.codebeat.ro

Re: [Trinidad] navigationTree not refactored???

2007-10-08 Thread Adam Winer

Ah, OK, I see the confusion.

The renderer in uix handles the decoding side of things.
The renderer in uinode handles just the rendering thing,
'cause it's from an old architecture that didn't have any
built-in decoding.

Ideally, we'd have one new renderer in core.xhtml that
extends TreeRenderer in core.xhtml.

-- Adam


On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote:
 Hi Adam!

 No problem, I'll do it.
 But I need to know some start points...
 i.e. It took me some 1/2 hour to figure that the actual renderer that does
 the job
 is the NavigationTreeRenderer from ui.laf.desktop package not the close to
 useless one from the uix package.

 Is something from the uix package classes really needed in this case?
 Should I rely on the old ComandNavigationRenderer or refactor that too?

 Please tell from where to start (so I don't loose to much time)
 and what things should I look for (not to mess it up).

 I really need this and I have a very short time for this. (wednesday at
 noon)


 On 10/9/07, Adam Winer [EMAIL PROTECTED] wrote:
  It's desperately in need of refactoring to extend off of
  the new TreeRenderer, and not the old 'uix' one.
 
  -- Adam
 
 
  On 10/8/07, Cristi Toth [EMAIL PROTECTED] wrote:
   Hi all!
  
   I need I really need the navigationTree and I noticed the renderer is
 still
   in the 'uix' package
   and that the code is... still old style and I don't understand nothing.
   It's extremely short and I didn't figure it out where's all the
 rendering
   implemented.
  
   Can somebody help me with some hints?
   I would like to refactor it and enhance its skinning (which for now
 seems to
   be disabled)
  
   --
   Cristi Toth
  
   -
   Codebeat
www.codebeat.ro
 



 --

 Cristi Toth

 -
 Codebeat
  www.codebeat.ro

Re: [Trinidad] please comment on the following bug

2007-10-06 Thread Adam Winer

Here's the background:
- The ::, ::: support is relatively recent.
- Because of that, there originally was no way for a table to
  be triggered by anything but its own children, since a table
  is a naming container!

This was a high priority issue back in the day, and the fix (then)
was to change addPartialTriggerListeners() from using the component
itself to the parent.  And, sadly, the documentation didn't follow.

So, to answer one question - how many users are dependent on this
broken behavior - the answer is TONS.  Change it, and you'll
break partialTriggers on all tables.  Which is bad.

The question of how many people rely on the behavior of ::
when you're on a non-naming container whose immediate parent
is a naming container is far trickier to answer.  Someone out there
will care, and have their code broken, but it's not the massive hell
that changing it for components that are themselves naming
containers would be.

My recommendation is to change the code and documentation to:
 - If the component is a naming container, search relative to the
   parent;  otherwise search relative to the component

Then the next question is whether, on failure for the non-NC
case, we should do a second search relative to the parent,
just for backwards compatibility, but deprecate that pattern
(perhaps by logging at INFO that a deprecated usage of
partialTriggers is in effect).

-- Adam


On 10/5/07, Andrew Robinson [EMAIL PROTECTED] wrote:
 The API for the partialTriggers seems to be broken for Trinidad trunk
 components. The bug is:

 https://issues.apache.org/jira/browse/TRINIDAD-757

 Please review the comments and offer any opinions on changing the
 current method to match the documentation. Also please check that we
 are right.

 Thanks,
 Andrew

Re: [Trinidad] ValueExpression in 1.2 and ValueBinding in 1.1

2007-09-29 Thread Adam Winer

For brand new APIs, I'm very tempted not to add backwards compatibility
to the 1.2 branch.  Dunno, could go either way on this one.

-- Adam


On 9/27/07, Jeanne Waldman [EMAIL PROTECTED] wrote:


 Matthias Wessendorf wrote:
 Hi,


 My understanding is that Trinidad trunk cannot use ValueExpression.
Is this
 true?

 yes, the ValueExpression comes from the unified el, which is part of JSP
 2.1


 If so, is it ok to have an API that takes ValueBinding in trunk
 and
ValueExpression in 1.2*branch?
In other words, does the 1.2* branch of
 Trinidad have to keep backward
compatibility, thus I would have a deprecated
 constructor that takes
ValueBinding and another constructor that takes
 ValueExpression.

 I think doing the two constructors, where one takes VBinding and
 is
deprecated is OK.
JSF API itself also keeps the old methods for
 backward compatibility
and adds new APIs that
work w/ the javax.el clazzes

 Yeah, I was wondering what our policy is for backward compatibility between
 ValueExpression and ValueBinding.
 I see we do it in some places (e.g., FacesBean) but not others (e.g.,
 DateTimeRangeValidator).

 -M


 Thanks,
Jeanne

Re: Opinion on a possible page flow scope bug

2007-09-28 Thread Adam Winer

It's a long-standing problem with form URL encoding.

If you don't add anything to pageFlowScope until Render Response,
those objects will be lost, 'cause the token is written out on the
form too early.  We try to be conservative and not generate new
pageFlowScopes unless its necessary.

The workaround is to make sure that at least one object
gets set on the pageFlowScope by beforePhase() of
Render Response.  Could be :
  pageFlowScope.put(foo, bar);
... doesn't matter what.

-- Adam


On 9/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
 Hi all,

 We have a client who played with page flow scope and bit and came to the
 following. Of course, the use case is extremely synthetic, but it's still
 strange:

 page.jspx
 f:view
   tr:document
 tr:form
   tr:inputText value=#{bean.value}/
   tr:commandButton text=Go/
  /tr:form
   /tr:document
  /f:view

 Bean.java
  public class Bean
 {
   public Bean()
   {
 RequestContext rContext =
 RequestContext.getCurrentInstance ();

 MapString, Object pageFlowScope = rContext.getPageFlowScope();

 if (!pageFlowScope.containsKey(someKey))
 {
   System.out.println(Creating the long to create object and we sure
 don't want to create it twice for the page flow);
   pageFlowScope.put(someKey, getAnExpensiveToCreate Object());
 }
}

   public String getValue()
   {
 RequestContext rContext =
 RequestContext.getCurrentInstance ();

  MapString, Object pageFlowScope = rContext.getPageFlowScope();

 return
 ((SomeClass)pageFlowScope.get(someKey)).getStringAttribute();
   }

public void setValue(String value)
{
  RequestContext rContext =
 RequestContext.getCurrentInstance();

  MapString, Object pageFlowScope = rContext.getPageFlowScope();


 ((SomeClass)pageFlowScope.get(someKey)).setStringAttribute(value
 );
}
 }

 With that code, the expensive object is going to be created twice, when the
 page is first rendered and on first postback. This happen because at the
 time the form is rendered, the page flow scope is still empty (bean was
 never referenced) and the default behavior in that case is to not add the
 token to the action url thus losing the object. Therefore, if you change the
 page to

 page.jspx
  f:view
tr:document
 tr:outputText value=#{bean.value}/
  tr:form
tr:inputText value=#{bean.value}/
tr:commandButton text=Go/
  /tr:form
/tr:document
  /f:view

 Then the expensive object get created only once. Personally I think we
 should consider that a bug as it's very counter intuitive and hard to debug.
 Am I missing something?


 Regards,

 ~ Simon

Re: Opinion on a possible page flow scope bug

2007-09-28 Thread Adam Winer

Yeah, absolutely a hack.

Option #2 that I can think of is caching the action URL at
the start of the FormRenderer encoding, then re-querying it
at the end.  If it's changed, add Javascript to find the form
and overwrite the action.  Also gross, but at least it's not
as bad as adding a configuration switch.

-- Adam


On 9/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
 Yeah, that's what we figured while playing with it, but it's not the most
 elegant solution. Maybe we should make that configurable in trinidad-config
 (not supporting EL)? Most users can probably deal with the issue so it
 should not save the scope by default when it's empty, but users needing it
 would be able to without using that hack, because that's really what it is.

 ~ Simon


 On 9/28/07, Adam Winer [EMAIL PROTECTED] wrote:
  It's a long-standing problem with form URL encoding.
 
  If you don't add anything to pageFlowScope until Render Response,
  those objects will be lost, 'cause the token is written out on the
  form too early.  We try to be conservative and not generate new
  pageFlowScopes unless its necessary.
 
  The workaround is to make sure that at least one object
  gets set on the pageFlowScope by beforePhase() of
  Render Response.  Could be :
pageFlowScope.put (foo, bar);
  ... doesn't matter what.
 
  -- Adam
 
 
  On 9/28/07, Simon Lessard [EMAIL PROTECTED] wrote:
   Hi all,
  
   We have a client who played with page flow scope and bit and came to the
   following. Of course, the use case is extremely synthetic, but it's
 still
   strange:
  
   page.jspx
   f:view
 tr:document
   tr:form
 tr:inputText value=#{bean.value}/
 tr:commandButton text=Go/
/tr:form
 /tr:document
/f:view
  
   Bean.java
public class Bean
   {
 public Bean()
 {
   RequestContext rContext =
   RequestContext.getCurrentInstance ();
  
   MapString, Object pageFlowScope = rContext.getPageFlowScope();
  
   if (!pageFlowScope.containsKey(someKey))
   {
 System.out.println(Creating the long to create object and we sure
   don't want to create it twice for the page flow);
 pageFlowScope.put(someKey, getAnExpensiveToCreate Object());
   }
  }
  
 public String getValue()
 {
   RequestContext rContext =
   RequestContext.getCurrentInstance ();
  
MapString, Object pageFlowScope = rContext.getPageFlowScope();
  
   return
  
 ((SomeClass)pageFlowScope.get(someKey)).getStringAttribute();
 }
  
  public void setValue(String value)
  {
RequestContext rContext =
   RequestContext.getCurrentInstance();
  
MapString, Object pageFlowScope = rContext.getPageFlowScope();
  
  
  
 ((SomeClass)pageFlowScope.get(someKey)).setStringAttribute(value
   );
  }
   }
  
   With that code, the expensive object is going to be created twice, when
 the
   page is first rendered and on first postback. This happen because at the
   time the form is rendered, the page flow scope is still empty (bean was
   never referenced) and the default behavior in that case is to not add
 the
   token to the action url thus losing the object. Therefore, if you change
 the
   page to
  
   page.jspx
f:view
  tr:document
   tr:outputText value=#{ bean.value}/
tr:form
  tr:inputText value=#{bean.value}/
  tr:commandButton text=Go/
/tr:form
  /tr:document
/f:view
  
   Then the expensive object get created only once. Personally I think we
   should consider that a bug as it's very counter intuitive and hard to
 debug.
   Am I missing something?
  
  
   Regards,
  
   ~ Simon

Re: [Trinidad] Skinning the tree

2007-09-28 Thread Adam Winer

I agree with Jeanne's suggestions - and also with Martin!
These will be great (and long overdue) improvements.

Cheers,
Adam

On 9/27/07, Martin Marinschek [EMAIL PROTECTED] wrote:
 Perfect.

 With these additions and some more detailed skinning of the table
 paging and sorting, we might get rid of the +/- statement about
 design for Trinidad at http://www.jsfmatrix.net.

 regards,

 Martin

 On 9/27/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
 
 
 
   Cristi Toth wrote:
  Hi all,
 
   I've done some work on the tree renderer in Trinidad
   I added the connecting lines, like in Tomahawk (or any other tree) behind
  the expanded/collapsed icon (-, +)
   I now have 5 skin-selectors for the tree:
 
   af|tree::expanded-icon
   af|tree::collapsed-icon
   - these are the [-], [+] icons
 
   af|tree::line-icon - this one is the vertical line
   af|tree::line-middle-icon - this one is the horizontal line for each entry
  (used in the back of the expanded/collapsed icon)
   af|tree::line-last-icon - this one is like the one above, but it is used in
  the case of the last sibling (the corner)
 
   now some questions:
 
   1) should I add a 'renderLines' attribute to the 'tree' component to
  enable/disable the lines ?
   I would make this a skin property, not a per instance component property.
  Something like:
   af|tree { -tr-render-lines: true}
 
 
   2) should I let the lines be skinnable and add them to the base skin?
   it's up to you. Showing/hiding them with the skin property probably is
  enough.
 
 
   3) if I let them be skinnable, then should I ommit the 'renderLines' attr
  and let the user just override the line icons with blank ones?
   again, I think this should be a skin property.
 
 
 
   Next, I worked on the TreeTable renderer. I made the 'Expand All / Collapse
  All' links skinnable.
 
   1. should I move the the 'Expand All / Collapse All' links on the first row
  and get rid of the 2nd ?
   It seems quite useless to have 2 rows
   not sure what you mean.
 
 
   2. should I also make the focus link 'X' skinnable (it looks kind of lame
  right now) ?
   sure. I'm surprised it isn't already.
 
 
   3. should I add some attributes for disabling the focus column and the
  breadCrumbs, for people who don't need them?
 
   4. I noticed a bug in the row banding, it's not correctly rendered, I
  suppose it would be nice if I fix it...
 
   You can see here a pictures with the results of what I did until now:
   http://people.apache.org/~ckormos/tree_skinning.png
 
   Is this welcomed by you guys?
   I like it.
 
 
   regards,
   --
   Cristi Toth
 
   -
   Codebeat
   www.codebeat.ro


 --

 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 Trinidad plugins (1.2.3))

Yeah, absolutely, I agree.  Any reasonable -1 should be
taken seriously, even from a non-committer.

-- Adam


On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 that was not related to your vote :-)
 That was just an update on the release-voting process ;-)

 If for instance, a user finds a very important thing, that REALLY
 needs to be fixed before doing a release. Her/His -1 vote will get
 attention as well ;-)

 -Matthias

 On 9/26/07, Andrew Robinson [EMAIL PROTECTED] wrote:
  FYI, remember that my vote is not official, I am a committer, not a
  PMC/voting member.
 
  -Andrew
 
  On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Hi,
  
   we got five +1 votes:
  
   -Matthias Wessendorf
   -Andrew Robinson
   -Grant Smith
   -Simon Lessard
   -Adam Winer
  
   Afterwards, we got a -1 from Andrew Robinson, but he made a withdraw
   of his -1 vote.
  
   Note, that there is no veto on a release:
   http://www.apache.org/foundation/voting.html#ReleaseVotes
  
   But usually a -1 is a valid reason to rethink the release!
   Not needed here, because the withdraw of Andrew's -1 ;-)
  
   I'll follow up w/ the required announcement etc.
  
   -Matthias
  
   On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
   
I was running the needed tasks to get the 1.2.3 release of the Apache
MyFaces Trinidad Maven 2 Plugins out. Note, that this is the first 
version
of the unified Trinidad plugins, that will be used for our JSF 1.1 and
JSF 1.2 CORE.
The artifacts are deployed to my private Apache account ([1]).
   
Please take a look at the 1.2.3 artifacts and vote.
   
How to test those JARs ?
   
1. there is now a zip file (org.zip) (see [1])
2. use the stage repo inside your pom.xml file:
...
pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/123-plugins/url
  layoutdefault/layout
 /pluginRepository
/pluginRepositories
...
   

[ ] +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
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: [vote] release of Trinidad plugins (1.2.3)

Yeah, no one has had any incentive yet to implement non-Trinidad 1.1
component generation.  I don't know anyone that's working on it.

-- Adam


On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Should this be filed as a bug, or is it a known issue / work in progress?

 I think that is the case, because Bruno enabled it (maven-faces-plg)
 to generate our JSF 1.2 MyFaces Core stuff.

 -Matthias

 
  -Andrew
 
  On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Hi,
  
   I was running the needed tasks to get the 1.2.3 release of the Apache
   MyFaces Trinidad Maven 2 Plugins out. Note, that this is the first version
   of the unified Trinidad plugins, that will be used for our JSF 1.1 and
   JSF 1.2 CORE.
   The artifacts are deployed to my private Apache account ([1]).
  
   Please take a look at the 1.2.3 artifacts and vote.
  
   How to test those JARs ?
  
   1. there is now a zip file (org.zip) (see [1])
   2. use the stage repo inside your pom.xml file:
   ...
   pluginRepositories
pluginRepository
idapache.stage/id
nameApache Stage Repository/name
urlhttp://people.apache.org/~matzew/123-plugins/url
 layoutdefault/layout
/pluginRepository
   /pluginRepositories
   ...
  
   
   [ ] +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
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

[jira] Created: (TRINIDAD-742) RenderKit test framework doesn't load RenderKitFactories from faces-config.xml

2007-09-26 Thread Adam Winer (JIRA)

RenderKit test framework doesn't load RenderKitFactories from faces-config.xml
--

 Key: TRINIDAD-742
 URL: https://issues.apache.org/jira/browse/TRINIDAD-742
 Project: MyFaces Trinidad
  Issue Type: Test
Affects Versions: 1.0.2-core
Reporter: Adam Winer
Assignee: Adam Winer


The RenderKit test framework currently hardcodes CoreRenderKitFactory, but 
doesn't support any 3rd party renderkit factories.  This makes it hard to test 
anything that relies on an extended factory.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-742) RenderKit test framework doesn't load RenderKitFactories from faces-config.xml

2007-09-26 Thread Adam Winer (JIRA)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer resolved TRINIDAD-742.
-

Resolution: Fixed

Fixed.

 RenderKit test framework doesn't load RenderKitFactories from faces-config.xml
 --

 Key: TRINIDAD-742
 URL: https://issues.apache.org/jira/browse/TRINIDAD-742
 Project: MyFaces Trinidad
  Issue Type: Test
Affects Versions: 1.0.2-core
Reporter: Adam Winer
Assignee: Adam Winer

 The RenderKit test framework currently hardcodes CoreRenderKitFactory, but 
 doesn't support any 3rd party renderkit factories.  This makes it hard to 
 test anything that relies on an extended factory.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [vote] release of Trinidad core (1.0.3)

Oops...  I just checked in a fix for TRINIDAD-742:
 RenderKit test framework doesn't load RenderKitFactories from faces-config.xml
Any chance of re-spinning the release candidate?

-- Adam


On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 +1

 On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi,
 
  I was running the needed tasks to get the 1.0.3 release of the Apache
  MyFaces Trinidad CORE out. The artifacts are deployed to my private
  Apache account ([1]).
 
  Please take a look at the 1.0.3 artifacts and vote
 
  
  [ ] +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/core103/
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: [vote] release of Trinidad core (1.0.3)

And Danny Robinson also just checked in a fix for TRINIDAD-736...

-- Adam


On 9/26/07, Adam Winer [EMAIL PROTECTED] wrote:
 Oops...  I just checked in a fix for TRINIDAD-742:
  RenderKit test framework doesn't load RenderKitFactories from 
 faces-config.xml
 Any chance of re-spinning the release candidate?

 -- Adam


 On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  +1
 
  On 9/26/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Hi,
  
   I was running the needed tasks to get the 1.0.3 release of the Apache
   MyFaces Trinidad CORE out. The artifacts are deployed to my private
   Apache account ([1]).
  
   Please take a look at the 1.0.3 artifacts and vote
  
   
   [ ] +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/core103/
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org

Re: [vote] release of Trinidad plugins (1.2.3)

On 9/25/07, Andrew Robinson [EMAIL PROTECTED] wrote:
 I'm planning on help with the documentation, and plan to add a new
 page to the WIKI for a getting started on using the
 maven-faces-plugin with facelets and jsf 1.1.

That'd be awesome!

 On the topic of what I brought up, would it be better to have the
 component type ID filter be placed on the dynamic content only and not
 on the included content (meaning the component tags from the plugin,
 but do not filter the faces-config-base.xml content)?

That would be great, but...  it'd require some fun rearchitecting.
The filtering is done in XSLT, after the merge with the base doc
has already happened.  I agree that it's totally wacky that you explicitly
define something explicitly in faces-config-base.xml and then the
tool says nope, you must not have *really* wanted that!

-- Adam



 Is there a good reason that I can't think of at the moment to filter
 all the faces-config content and not just the generated content?

 -Andrew

 On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
  We should probably get serious about at least documenting the big
  gotchas of the faces plugin.  I've started a subsection at
  http://wiki.apache.org/myfaces/Trinidad_Plugins so we at least have
  somewhere to put this sort of info.  Andrew, stuff like this that you
  discover would be great additions.
 
  -- Adam
 
 
  On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote:
   After investigating the code more, it is working as designed, I just
   expected different results. Please disregard this previous email of
   mine.
  
   Thanks,
   Andrew
  
   On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Changing my vote to a possible -1 for the release.
   
I just posted an email about the plugin not including elements from
the faces-config-base.xml into the faces-config.xml. Unless I screwed
up somehow, I'd like to see if this can be fixed before the release.
   
-Andrew
   
On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
 On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

  
  [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..
  

 -- Adam

Re: [Trinidad] Branch for 1.0.3 core ?

I think Danny still has some things?

-- Adam


On 9/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 anyone else that has some changes to commit ?

 Otherwise I start the branch tomorrow morning (German time)

 -Matthias

 On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
  OK, I've fixed 735, and checked in the patches
  for 674 and 676.
 
  -- Adam
 
 
  On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
   We've also got patches available for TRINIDAD-718 and
   TRINIDAD-665 (actually looks like TRINIDAD-718 has
   already been checked in, but the JIRA wasn't closed).
  
   TRINIDAD-735 would be nice, but isn't critical.
  
   I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
   ASAP - straightforward fixes from Tomas Havelka, a shame
   to let them go unused.
  
   Anyone else have something they really want fixed for 1.0.3?
  
   Going forward, I don't think we need to have a strict
   release the plugins, then release core rule - I think we
   can mostly get away with just releasing core, when it's
   ready.  Which is good. :)
  
   -- Adam
  
  
   On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
Ok, commit is done on my side.
   
   
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Sounds good to me,
 this email was just a heads-up ;-)

 On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
  I need to commit the patch for statusIndicator. I'll do that later
today, we
  should not release until it's done.
 
 
  On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   one more.
  
   from September 30th = October 15th (incl.) I am away from any
computer !
  :-)
   (vacation)
  
   So, the goal of this email was to prepare as much as possible to 
   get
   the release out
   by end of this week ;-)
  
   Otherwise someone else needs to do the release procedure.
  
   -Matthias
  
   On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
On 9/24/07, Danny Robinson  [EMAIL PROTECTED] wrote:
 Did I miss the conversation leading up to this, or is this it?
   
there was no thread regarding this.
   
Usually after the release of the plugins, we start with the 
release
procedure of the core.
Since the vote on plugins is already ongoing, I was asking if we
should wait more days or not.
Looks like you've something for the 1.0.3, so we wait. That's 
fine.
   
-M
   

 To Do
 * resolve the current xOffset/yOffset conversation and fix the
plugins
 * Update AutoSubmitUtils to output ' TrPage._autoSubmit()' as 
 the
  onchange
 handler

 Danny


 On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi,
 
  I'd like to branch today for the upcoming 1.0.3-core 
  release of
  Trinidad. Does one need to commit something before ?
 
  thx,
  Matthias
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org
 



 --
 Chordiant Software Inc.
  www.chordiant.com
   
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

   
   
  
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: [Trinidad] Branch for 1.0.3 core ?

This looks like it fails if validation is set to alert mode;  _autoSubmit
always calls _validateInput, which calls _validateInline.

Also, if immediate is true, the _autoSubmit param validateForm is true?
That seems weird...

I think I've seen this code:
+  if (_agent.isIE)
+  {
+// in many forms there is a hidden field named event
+// Sometimes IE gets confused and sends us that instead of
+// the true event, so...
+if (event[type] == hidden)
+  event = window.event;
+  }
+

... elsewhere.  Never a good thing to cut-and-paste in JS.

-- Adam


On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:
 I'd like some quick eyes on the patch I've attached to TRINIDAD-37 which I'd
 like to commit if there are no issues.




 On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
  I think Danny still has some things?
 
  -- Adam
 
 
  On 9/25/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   anyone else that has some changes to commit ?
  
   Otherwise I start the branch tomorrow morning (German time)
  
   -Matthias
  
   On 9/25/07, Adam Winer [EMAIL PROTECTED] wrote:
OK, I've fixed 735, and checked in the patches
for 674 and 676.
   
-- Adam
   
   
On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
 We've also got patches available for TRINIDAD-718 and
 TRINIDAD-665 (actually looks like TRINIDAD-718 has
 already been checked in, but the JIRA wasn't closed).

 TRINIDAD-735 would be nice, but isn't critical.

 I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
 ASAP - straightforward fixes from Tomas Havelka, a shame
 to let them go unused.

 Anyone else have something they really want fixed for 1.0.3?

 Going forward, I don't think we need to have a strict
 release the plugins, then release core rule - I think we
 can mostly get away with just releasing core, when it's
 ready.  Which is good. :)

 -- Adam


 On 9/24/07, Simon Lessard  [EMAIL PROTECTED] wrote:
  Ok, commit is done on my side.
 
 
  On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   Sounds good to me,
   this email was just a heads-up ;-)
  
   On 9/24/07, Simon Lessard  [EMAIL PROTECTED] wrote:
I need to commit the patch for statusIndicator. I'll do that
 later
  today, we
should not release until it's done.
   
   
On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 one more.

 from September 30th = October 15th (incl.) I am away from
 any
  computer !
:-)
 (vacation)

 So, the goal of this email was to prepare as much as
 possible to get
 the release out
 by end of this week ;-)

 Otherwise someone else needs to do the release procedure.

 -Matthias

 On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  On 9/24/07, Danny Robinson  [EMAIL PROTECTED]
 wrote:
   Did I miss the conversation leading up to this, or is
 this it?
 
  there was no thread regarding this.
 
  Usually after the release of the plugins, we start with
 the release
  procedure of the core.
  Since the vote on plugins is already ongoing, I was asking
 if we
  should wait more days or not.
  Looks like you've something for the 1.0.3, so we wait.
 That's fine.
 
  -M
 
  
   To Do
   * resolve the current xOffset/yOffset conversation and
 fix the
  plugins
   * Update AutoSubmitUtils to output '
 TrPage._autoSubmit()' as the
onchange
   handler
  
   Danny
  
  
   On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED]
 wrote:
Hi,
   
I'd like to branch today for the upcoming 1.0.3-core
 release of
Trinidad. Does one need to commit something before ?
   
thx,
Matthias
   
--
Matthias Wessendorf
   
further stuff:
blog:
 http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
  
  
   --
   Chordiant Software Inc.
www.chordiant.com
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog:
 http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org
 


 --
 Matthias Wessendorf

 further stuff:
 blog:
 http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

   
   
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org

Re: [jira] Resolved: (TRINIDAD-731) xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity.

It's probably the case that the component and JSP tag methods
need to be setxOffset instead of setXOffset() - or you need to
supply a BeanInfo.

But the best and simplest option, I think, is just to rename the
properties to xoffset and yoffset, no caps - like halign and valign.

-- Adam

On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:
Both.

If you grab the trunk and tweak the CorePanelPopup.xml attributes back to
using xOffset/yOffset, then also tweak findTypeConstants() in the renderer,
then...

In JSP, you get

/components/panelPopup.jspx(39,102) Unable to find setter
method for attribute: yOffset

In Facelets, you get
java.lang.ClassCastException: java.lang.String
at
org.apache.myfaces.trinidad.render.CoreRenderer.toInt(CoreRenderer.java:127)
at
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.PanelPopupRenderer.getHorzOffset
(PanelPopupRenderer.java:103)

as the attribute gets read, but is held internally as a String

I took a look around the generated artifacts, but nothing jumps out as
wrong.

On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
Remind me what the issue is? Is it JSP tags,
Facelets, both, something else?

-- Adam

On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote:
I know. When I made the name changes, I knew the plugins should really
get
fixed ;-). Any hints on where to look in the plugins would really help
(unknown territory), then I can get the attribute names reverted.

On 9/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Yech, why don't we just fix the plugins???

-- Adam

On 9/21/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hard to say that they are breaking, because I'm not certain they
ever
worked
;-)

I'll update the release notes to cover this though.

On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Is this a compatibility breaking change (meaning that the old
attributes were removed)?

If so, were are these items documented so that users know what
happened?

-Andrew

On 9/21/07, Danny Robinson (JIRA) dev@myfaces.apache.org wrote:

[

https://issues.apache.org/jira/browse/TRINIDAD-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Danny Robinson resolved TRINIDAD-731.
-

Resolution: Fixed
Fix Version/s: 1.0.3-core

Switched attribute names to horzOffset and vertOffset.

xOffset/yOffset don't get correctly processed by plugins,
switch
to
horzOffset/vertOffset for simplicity and clarity.

Key: TRINIDAD-731
URL:
https://issues.apache.org/jira/browse/TRINIDAD-731
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 1.0.3-core
Reporter: Danny Robinson
Assignee: Danny Robinson
Priority: Minor
Fix For: 1.0.3-core

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue
online.

--
Chordiant Software Inc.
www.chordiant.com

Chordiant Software Inc.
www.chordiant.com

Re: [Trinidad] Branch for 1.0.3 core ?

On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:

  This looks like it fails if validation is set to alert mode;  _autoSubmit
  always calls _validateInput, which calls _validateInline.

 Thanks, fixed.

  Also, if immediate is true, the _autoSubmit param validateForm is true?
  That seems weird...

 BodyRenderer actually uses the snippet below, so whole-form validation
 shouldn't happen if immediate is true.
 builder.append(immediate ? 0 : 1);

  I think I've seen this code:
  +  if (_agent.isIE)
  +  {
  +// in many forms there is a hidden field named event
  +// Sometimes IE gets confused and sends us that instead of
  +// the true event, so...
  +if (event[type] == hidden)
  +  event = window.event;
  +  }
  +
 
  ... elsewhere.  Never a good thing to cut-and-paste in JS.

 Do you mean abstract both copies into a common method, or are you
 questioning the actual code.

Both should go into a common method, I think.  Maybe
we could start to use some polymorphism on the agent object,
so you could just call event = _agent.getEvent(event)?

-- Adam


  If that's the case, I spent a few hours one
 evening trying to understand why I wasn't getting the 'real' event object in
 IE.


  -- Adam
 
 
  On 9/25/07, Danny Robinson  [EMAIL PROTECTED] wrote:
   I'd like some quick eyes on the patch I've attached to TRINIDAD-37 which
 I'd
   like to commit if there are no issues.
  
  
  
  
   On 9/25/07, Adam Winer  [EMAIL PROTECTED] wrote:
I think Danny still has some things?
   
-- Adam
   
   
On 9/25/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 anyone else that has some changes to commit ?

 Otherwise I start the branch tomorrow morning (German time)

 -Matthias

 On 9/25/07, Adam Winer [EMAIL PROTECTED]  wrote:
  OK, I've fixed 735, and checked in the patches
  for 674 and 676.
 
  -- Adam
 
 
  On 9/24/07, Adam Winer  [EMAIL PROTECTED] wrote:
   We've also got patches available for TRINIDAD-718 and
   TRINIDAD-665 (actually looks like TRINIDAD-718 has
   already been checked in, but the JIRA wasn't closed).
  
   TRINIDAD-735 would be nice, but isn't critical.
  
   I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
   ASAP - straightforward fixes from Tomas Havelka, a shame
   to let them go unused.
  
   Anyone else have something they really want fixed for 1.0.3?
  
   Going forward, I don't think we need to have a strict
   release the plugins, then release core rule - I think we
   can mostly get away with just releasing core, when it's
   ready.  Which is good. :)
  
   -- Adam
  
  
   On 9/24/07, Simon Lessard  [EMAIL PROTECTED]  wrote:
Ok, commit is done on my side.
   
   
On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 Sounds good to me,
 this email was just a heads-up ;-)

 On 9/24/07, Simon Lessard  [EMAIL PROTECTED]
 wrote:
  I need to commit the patch for statusIndicator. I'll do
 that
   later
today, we
  should not release until it's done.
 
 
  On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED] 
 wrote:
   one more.
  
   from September 30th = October 15th (incl.) I am away
 from
   any
computer !
  :-)
   (vacation)
  
   So, the goal of this email was to prepare as much as
   possible to get
   the release out
   by end of this week ;-)
  
   Otherwise someone else needs to do the release
 procedure.
  
   -Matthias
  
   On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED]
 wrote:
On 9/24/07, Danny Robinson  [EMAIL PROTECTED]
 
   wrote:
 Did I miss the conversation leading up to this, or
 is
   this it?
   
there was no thread regarding this.
   
Usually after the release of the plugins, we start
 with
   the release
procedure of the core.
Since the vote on plugins is already ongoing, I was
 asking
   if we
should wait more days or not.
Looks like you've something for the 1.0.3, so we wait.
   That's fine.
   
-M
   

 To Do
 * resolve the current xOffset/yOffset conversation
 and
   fix the
plugins
 * Update AutoSubmitUtils to output '
   TrPage._autoSubmit()' as the
  onchange
 handler

 Danny


 On 9/24/07, Matthias Wessendorf  [EMAIL PROTECTED]
 
   wrote:
  Hi,
 
  I'd like to branch today for the upcoming
 1.0.3-core
   release of
  Trinidad. Does one need to commit something before
 ?
 
  thx,
  Matthias

Re: [Trinidad] Branch for 1.0.3 core ?

Sure, no prob. :)

-- Adam


On 9/25/07, Danny Robinson [EMAIL PROTECTED] wrote:

  Both should go into a common method, I think.  Maybe
  we could start to use some polymorphism on the agent object,
  so you could just call event = _agent.getEvent(event)?

 That would be no bad thing,  there's also
 addEventHandler/removeEventHandler stuff we could also add
 there.

 Given the timing, I'm going to put a comment in the code and create an issue
 for this down stream.

 Danny

Re: [vote] release of Trinidad plugins (1.2.3)

On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:

 
 [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..
 

-- Adam

[jira] Commented: (TRINIDAD-695) tr:form skips c/s validation on submit by 'defaultCommand'


[ 
https://issues.apache.org/jira/browse/TRINIDAD-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12529893
 ] 

Adam Winer commented on TRINIDAD-695:
-

Easy to turn on client-side validation: in Core.js, _submitOnEnter,
change
submitForm(frm,0,params);
to
submitForm(frm,1,params);

But we can only change that 0 to 1 if the button isn't immediate, which
is not easy.


 tr:form skips c/s validation on submit by 'defaultCommand'
 --

 Key: TRINIDAD-695
 URL: https://issues.apache.org/jira/browse/TRINIDAD-695
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.0.2-core
Reporter: Vadim Dmitriev

 tr:form skips client-side validation when submitted by defaultCommand.
 For example:
 tr:form defaultCommand=submitter
   tr:inputText value= required=true /
   tr:commandButton id=submitter /
 /tr:form
 will produce c/s validation errors when tr:commandButton clicked, but will 
 submit form to server if 'enter' is pressed while in tr:inputText.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] Branch for 1.0.3 core ?

We've also got patches available for TRINIDAD-718 and
TRINIDAD-665 (actually looks like TRINIDAD-718 has
already been checked in, but the JIRA wasn't closed).

TRINIDAD-735 would be nice, but isn't critical.

I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
ASAP - straightforward fixes from Tomas Havelka, a shame
to let them go unused.

Anyone else have something they really want fixed for 1.0.3?

Going forward, I don't think we need to have a strict
release the plugins, then release core rule - I think we
can mostly get away with just releasing core, when it's
ready.  Which is good. :)

-- Adam


On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
 Ok, commit is done on my side.


 On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Sounds good to me,
  this email was just a heads-up ;-)
 
  On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
   I need to commit the patch for statusIndicator. I'll do that later
 today, we
   should not release until it's done.
  
  
   On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
one more.
   
from September 30th = October 15th (incl.) I am away from any
 computer !
   :-)
(vacation)
   
So, the goal of this email was to prepare as much as possible to get
the release out
by end of this week ;-)
   
Otherwise someone else needs to do the release procedure.
   
-Matthias
   
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 On 9/24/07, Danny Robinson  [EMAIL PROTECTED] wrote:
  Did I miss the conversation leading up to this, or is this it?

 there was no thread regarding this.

 Usually after the release of the plugins, we start with the release
 procedure of the core.
 Since the vote on plugins is already ongoing, I was asking if we
 should wait more days or not.
 Looks like you've something for the 1.0.3, so we wait. That's fine.

 -M

 
  To Do
  * resolve the current xOffset/yOffset conversation and fix the
 plugins
  * Update AutoSubmitUtils to output ' TrPage._autoSubmit()' as the
   onchange
  handler
 
  Danny
 
 
  On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Hi,
  
   I'd like to branch today for the upcoming 1.0.3-core release of
   Trinidad. Does one need to commit something before ?
  
   thx,
   Matthias
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 
 
 
  --
  Chordiant Software Inc.
   www.chordiant.com


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

   
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org

[jira] Resolved: (TRINIDAD-676) Component selectRangeChoiceBar not properly rendered (2nd issue)


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-676?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer resolved TRINIDAD-676.
-

   Resolution: Fixed
Fix Version/s: 1.0.3-core
 Assignee: Adam Winer

Checked in patch, thanks!

 Component selectRangeChoiceBar not properly rendered (2nd issue)
 

 Key: TRINIDAD-676
 URL: https://issues.apache.org/jira/browse/TRINIDAD-676
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.0.1-core, 1.0.2-core
Reporter: Tomas Havelka
Assignee: Adam Winer
 Fix For: 1.0.3-core


 Another issue with selectRangeChoiceBar and not known model row count. As I 
 see, SelectRangeChoiceBarRenderer rendering routine is one-indexed, but model 
 is zero-based. Then when searching for next value by asking model's 
 isRowAvailable method, value has to be decreased.
 Solution:
 Modify encodeAll method on line 374 of SelectRangeChoiceBarRenderer like this.
 hasNextRecords = isRowAvailable(component, (int)nextValue - 1);

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (TRINIDAD-674) Component selectRangeChoiceBar not properly rendered


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer resolved TRINIDAD-674.
-

   Resolution: Fixed
Fix Version/s: 1.0.3-core
 Assignee: Adam Winer

Checked in patch, thanks!

 Component selectRangeChoiceBar not properly rendered
 

 Key: TRINIDAD-674
 URL: https://issues.apache.org/jira/browse/TRINIDAD-674
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.0.1-core, 1.0.2-core
Reporter: Tomas Havelka
Assignee: Adam Winer
 Fix For: 1.0.3-core


 When component selectRangeChoiceBar is rendered for the last page and model 
 row count is not known (-1), the link for the navigation to next page should 
 be rendered as disabled (now it's rendered as enabled even if no onclick 
 event is attached).
 Solution:
 Modify _renderLink method of SelectRangeChoiceBarRenderer similarly to 
 _renderArrow method. For example like this.
 String text = getBlockString(arc, isNext, records);
 boolean isEnabled = ((records  0)  (onclick != null));  // here is the 
 place to check whether link is to be rendered as disabled
 ResponseWriter writer = context.getResponseWriter();
 if (isEnabled)
 {
   writer.startElement(a, null);
   writer.writeURIAttribute(href, #, null);
   writer.writeAttribute(onclick, onclick, null);
   // The navBar needs its initial focus to be on the Next button,
   // according to the BLAF. Render a special id on the Next button
   // if this navBar is to have the initial focus. (unless it needs
   // initial focus, the Next button does not have an id on it)
   if (isNext)
   {
 String linkID = _getIDForFocus(arc, id);
 writer.writeAttribute(id, linkID, null);
   }
   renderStyleClass(context, arc, SkinSelectors.NAV_BAR_ALINK_STYLE_CLASS);
 }
 else
 {
   writer.startElement(span, null);
   renderStyleClass(context, arc, SkinSelectors.NAV_BAR_ILINK_STYLE_CLASS);
 }
 writer.writeText(text, null);
 if (isEnabled)
 {
   writer.endElement(a);
 }
 else
 {
   writer.endElement(span);
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-642) UIXTable.createCollectionModel throws null pointer exception if selectedRowKeys evaluates to null


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-642?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer updated TRINIDAD-642:


Status: Patch Available  (was: Open)

 UIXTable.createCollectionModel throws null pointer exception if 
 selectedRowKeys evaluates to null
 -

 Key: TRINIDAD-642
 URL: https://issues.apache.org/jira/browse/TRINIDAD-642
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.1-core
Reporter: Max Starets
 Attachments: jira-642.patch


 UIXTable.createCollectionModel() expects that selectedRowKeys and 
 disclosedRowKeys are always non-null.
 To avoid null-pointer exceptions, we need two fixes:
 1) Call _init() in UIXCollection.invokeOnComponent() to ensure that these 
 properties are initialized;
 2) If the properties are still null in createColelctionModel() (presumably 
 because the values were EL-bound and
 got evaluated to null, but the _init() did not proceed because UIXColelction 
 has already been initialized), we need
 to manually allocate RowKeySetImpl object and set the properties

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-734) EL expression used for node labels gets evaluated only once


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer updated TRINIDAD-734:


Status: Patch Available  (was: Open)

 EL expression used for node labels gets evaluated only once
 ---

 Key: TRINIDAD-734
 URL: https://issues.apache.org/jira/browse/TRINIDAD-734
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Gary Kind
 Attachments: 122Branch.patch, trunk.patch


 The first time the actionListener calls the getLabel() method for a menu 
 node, if the stored label is an EL expression, it gets evaluated correctly 
 and the returned String is set on the label.  However, before this fix, the 
 evaluated String was set as the label for the menu item node.  This means 
 that the next time the getLabel() method is called, the EL expression is not 
 again evaluated as it should.  The String from the first time it was 
 evaluated is returned instead.  This is incorrect as it prevents an EL 
 expression from changing the label dynamically.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-734) EL expression used for node labels gets evaluated only once


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-734?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer updated TRINIDAD-734:


   Resolution: Fixed
Fix Version/s: 1.0.3-core
 Assignee: Jeanne Waldman
   Status: Resolved  (was: Patch Available)

Fix checked in by Jeanne.

 EL expression used for node labels gets evaluated only once
 ---

 Key: TRINIDAD-734
 URL: https://issues.apache.org/jira/browse/TRINIDAD-734
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Gary Kind
Assignee: Jeanne Waldman
 Fix For: 1.0.3-core

 Attachments: 122Branch.patch, trunk.patch


 The first time the actionListener calls the getLabel() method for a menu 
 node, if the stored label is an EL expression, it gets evaluated correctly 
 and the returned String is set on the label.  However, before this fix, the 
 evaluated String was set as the label for the menu item node.  This means 
 that the next time the getLabel() method is called, the EL expression is not 
 again evaluated as it should.  The String from the first time it was 
 evaluated is returned instead.  This is incorrect as it prevents an EL 
 expression from changing the label dynamically.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [jira] Resolved: (TRINIDAD-731) xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity.

Remind me what the issue is? Is it JSP tags,
Facelets, both, something else?

-- Adam

On 9/24/07, Danny Robinson [EMAIL PROTECTED] wrote:
I know. When I made the name changes, I knew the plugins should really get
fixed ;-). Any hints on where to look in the plugins would really help
(unknown territory), then I can get the attribute names reverted.

On 9/21/07, Adam Winer [EMAIL PROTECTED] wrote:
Yech, why don't we just fix the plugins???

-- Adam

On 9/21/07, Danny Robinson [EMAIL PROTECTED] wrote:
Hard to say that they are breaking, because I'm not certain they ever
worked
;-)

I'll update the release notes to cover this though.

On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote:
Is this a compatibility breaking change (meaning that the old
attributes were removed)?

If so, were are these items documented so that users know what
happened?

-Andrew

On 9/21/07, Danny Robinson (JIRA) dev@myfaces.apache.org wrote:

[

https://issues.apache.org/jira/browse/TRINIDAD-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Danny Robinson resolved TRINIDAD-731.
-

Resolution: Fixed
Fix Version/s: 1.0.3-core

Switched attribute names to horzOffset and vertOffset.

xOffset/yOffset don't get correctly processed by plugins, switch
to
horzOffset/vertOffset for simplicity and clarity.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

--
Chordiant Software Inc.
www.chordiant.com

[jira] Resolved: (TRINIDAD-735) '_checkLoad is not defined' error opening lightweight dialog in FireFox


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer resolved TRINIDAD-735.
-

   Resolution: Fixed
Fix Version/s: 1.0.3-core

Fixed.

 '_checkLoad is not defined' error opening lightweight dialog in FireFox
 ---

 Key: TRINIDAD-735
 URL: https://issues.apache.org/jira/browse/TRINIDAD-735
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.3-core
Reporter: Danny Robinson
Assignee: Adam Winer
Priority: Minor
 Fix For: 1.0.3-core


 The FF console reports '_checkLoad is not defined' when a lightweight dialog 
 is opened.  Nothing fails, but why this error is reported is very strange.  
 It  is somehow related to TrPopupDailog._initDialogPage(), which preceeds the 
 _checkLoad() call in the body onload handler, but in the two out of three 
 times is is called during a dialog open, _checkLoad seems to work fine.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (TRINIDAD-737) Need To Establish Currency for Table Events


 [ 
https://issues.apache.org/jira/browse/TRINIDAD-737?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adam Winer updated TRINIDAD-737:


   Resolution: Fixed
Fix Version/s: 1.0.3-core
   Status: Resolved  (was: Patch Available)

Checked in the patch - thanks!

 Need To Establish Currency for Table Events
 ---

 Key: TRINIDAD-737
 URL: https://issues.apache.org/jira/browse/TRINIDAD-737
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions: 1.2.2-core
Reporter: Max Starets
 Fix For: 1.0.3-core

 Attachments: TRINIDAD-737.diff


 We should establish currency for listeners to events filed by table, tree and 
 treeTable and by components contained within their facets. Note that this 
 does not include events fired by specific rows (these are establishing 
 currency already).
 The currency should be set to the first entry in the selected row key set.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Trinidad] Branch for 1.0.3 core ?

OK, I've fixed 735, and checked in the patches
for 674 and 676.

-- Adam


On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
 We've also got patches available for TRINIDAD-718 and
 TRINIDAD-665 (actually looks like TRINIDAD-718 has
 already been checked in, but the JIRA wasn't closed).

 TRINIDAD-735 would be nice, but isn't critical.

 I'll check in the fixes for TRINIDAD-674 and TRINIDAD-676
 ASAP - straightforward fixes from Tomas Havelka, a shame
 to let them go unused.

 Anyone else have something they really want fixed for 1.0.3?

 Going forward, I don't think we need to have a strict
 release the plugins, then release core rule - I think we
 can mostly get away with just releasing core, when it's
 ready.  Which is good. :)

 -- Adam


 On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
  Ok, commit is done on my side.
 
 
  On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Sounds good to me,
   this email was just a heads-up ;-)
  
   On 9/24/07, Simon Lessard [EMAIL PROTECTED] wrote:
I need to commit the patch for statusIndicator. I'll do that later
  today, we
should not release until it's done.
   
   
On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 one more.

 from September 30th = October 15th (incl.) I am away from any
  computer !
:-)
 (vacation)

 So, the goal of this email was to prepare as much as possible to get
 the release out
 by end of this week ;-)

 Otherwise someone else needs to do the release procedure.

 -Matthias

 On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  On 9/24/07, Danny Robinson  [EMAIL PROTECTED] wrote:
   Did I miss the conversation leading up to this, or is this it?
 
  there was no thread regarding this.
 
  Usually after the release of the plugins, we start with the release
  procedure of the core.
  Since the vote on plugins is already ongoing, I was asking if we
  should wait more days or not.
  Looks like you've something for the 1.0.3, so we wait. That's fine.
 
  -M
 
  
   To Do
   * resolve the current xOffset/yOffset conversation and fix the
  plugins
   * Update AutoSubmitUtils to output ' TrPage._autoSubmit()' as the
onchange
   handler
  
   Danny
  
  
   On 9/24/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
   
I'd like to branch today for the upcoming 1.0.3-core release of
Trinidad. Does one need to commit something before ?
   
thx,
Matthias
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
  
  
   --
   Chordiant Software Inc.
www.chordiant.com
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

   
   
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org

Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition

1. Evaluate the base ValueExpression (without looking at the string or
anything like that).
Call this object base. Call the property propertyName.
2. Get the ELResolver from Application and the ELContext from FacesContext
3. Call elResolver.getValue(elContext, base, propertyName);

You don't need to get types, or do instanceof, or anything like that!

-- Adam

On 9/24/07, Jeanne Waldman [EMAIL PROTECTED] wrote:

I need help understanding how you are expecting I use the
MapELResolver/ResourceBundleELResolver, Adam.

First, let me explain what I was doing. I was creating a ValueExpression
when I parsed the trinidad-skins.xml and found a value in
translation-source.

// could be Map or ResourceBundle, so make the type Object
return
LazyValueExpression.createValueExpression(translationSourceExpression,
Object.class);

I store this ValueExpression on the skin.

Then when getTranslatedValue is called, I would look up the key in the
resource cache that I lazily build.
A skin can have a bundle-name or it can have a translation-source, then if
the translation isn't found, it looks in all the skin additions bundle-name
or translation source, and then if it still isn't found it does the same
thing for the base skin, on up the chain until it finds it.
As I look into a map or resource bundle, I cache the entire map/resource
bundle, to make subsequent lookups faster.

To get the value from the translation source, I was planning to use the
ValueExpression's getValue and then figure out if it is a ResourceBundle
instance or a Map instance and proceed from there by caching the
Map/ResourceBundle keys/values in mylocale cache, then getting the key's
value, etc.

---
I don't what you mean when you say I should use a ELResolver. I'm a novice
with the ValueExpression, ELResolver code.

I'm guessing from reading the javadoc that you mean create an ELContext
that has a MapELResolver and another one for ResourceBundleELResolver.
Then I figure out what type the ValueExpression is, and then I use that
ELContext, and I take the 'key' in getTranslatedValue, and append that to
the ValueExpression somehow (or store the expression on the Skin as a String
instead of a VE and use that as the 'base') and get the value. I suppose I
can cache each key/value as I find it instead of caching the entire contents
like I do for the bundle-name code. But I'd rather be consistent.

Can you explain to me what you meant and iif/how that is better than the
way I was planning to do it?

Thanks!
Jeanne

Simon Lessard wrote:
EL implies a small performance overhead but I guess it's acceptable for the
gain here.

On 9/21/07, Adam Winer [EMAIL PROTECTED] wrote:
-1 to trying to turn everything into ResourceBundle. Just use EL -
ELResolver in 1.2, PropertyResolver in 1.1. As of 1.2, that gives
you ResourceBundle and Map support. In 1.1, only Map
(and bean, of course), but then again in 1.1 how do you get
unwrapped ResourceBundle instances into EL anyway?

@Gary: the Shale LoadBundle class seems quite unnecessary
in 1.2, right?

-- Adam

On 9/21/07, Gary VanMatre [EMAIL PROTECTED] wrote:

From: Simon Lessard [EMAIL PROTECTED]

If we accept only a map, it's quite exclusive, unless we add yet
another
tag, but I would be -1 on that. However, as Adam suggested, we could
call
it translation-source and support both Map and ResourceBundle
instances.
We have to a very thin adapter Map -- ResourceBundle if a Map instance
is
passed and the remaining code will continue to work as it's now, with a
ResourceBundle.

FWIW, Shale has a utility class that sounds very similar to what you
have
described [1].

[1]

http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/LoadBundle.java?view=markup

~ Simon

Gary

Re: [vote] release of Trinidad plugins (1.2.3)

We should probably get serious about at least documenting the big
gotchas of the faces plugin.  I've started a subsection at
http://wiki.apache.org/myfaces/Trinidad_Plugins so we at least have
somewhere to put this sort of info.  Andrew, stuff like this that you
discover would be great additions.

-- Adam


On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote:
 After investigating the code more, it is working as designed, I just
 expected different results. Please disregard this previous email of
 mine.

 Thanks,
 Andrew

 On 9/24/07, Andrew Robinson [EMAIL PROTECTED] wrote:
  Changing my vote to a possible -1 for the release.
 
  I just posted an email about the plugin not including elements from
  the faces-config-base.xml into the faces-config.xml. Unless I screwed
  up somehow, I'd like to see if this can be fixed before the release.
 
  -Andrew
 
  On 9/24/07, Adam Winer [EMAIL PROTECTED] wrote:
   On 9/23/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  

[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..

  
   -- Adam

[jira] Updated: (TOBAGO-485) tc:menu and links

2007-09-22 Thread adam (JIRA)


 [ 
https://issues.apache.org/jira/browse/TOBAGO-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

adam updated TOBAGO-485:


Status: Patch Available  (was: Open)

 tc:menu and links 
 

 Key: TOBAGO-485
 URL: https://issues.apache.org/jira/browse/TOBAGO-485
 Project: MyFaces Tobago
  Issue Type: Improvement
  Components: Core, Themes
Reporter: adam
Priority: Minor

 tc:menuBar
  tc:menu label=Home
  /tc:menu
 /tc:menuBar
 i need to make a link on the menu Home directly with out using 
 tc:menuItem . I need to know the answer plz asap.
 Thanks  Regards 
 M.Adam
 Junior Developer

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: TRINIDAD-729

I agree - in this case, you really want to add a delay with a JS window
timeout that keeps getting rescheduled (e.g., on every tick of the
counter, window.clearTimeout() if the timeout exists, then call
window.setTimeout()).

-- Adam


On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote:
 Is this a good idea?

 If the user wants to increase the counter 5 times, you would not want
 5 ajax calls for every time they click the up arrow.

 -Andrew

 On 9/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  Hi guys,
 
  I added a patch (and a comment) to TRINIDAD-729 (see [1]).
  I am not sure if there is an issue with this fix/patch.
  Do you mind to review it ?
 
  Thanks!
  Matthias
 
  [1] https://issues.apache.org/jira/browse/TRINIDAD-729
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org

Re: TRINIDAD-729

At the moment, this doesn't come up that commonly in the
Trinidad components.  But it could, if:
 -  We had an autosuggest component
 -  We supported autosubmit on any keypress in an input component,
 not just on tab-out

There's a separate queueing question that also comes up,
which is that currently, if you have nothing but autoSubmit fields,
and you change A, then B, then C, but we're still processing
A, you'd really like to join B+C in one submit, instead of separating
them into two.  For that, we really need an event queue (in addition
to our request queue.)  In theory, we could design the event
queue to address both problems (delivering two different
events together, collapsing duplicate events.)

-- Adam


On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote:
 Yes, thought crossed my mind as well for something like that.

 Perhaps a common type of JS queue could be made for this, as I would
 not be surprised if this functionality is revisited elsewhere.
 Something like a non-duplicate PPR list, when a new event is added,
 the previous is removed and each event has a timeout associated with
 it (fire after x millis).

 On 9/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  true,
 
  perhaps we can include TRINIDAD-730 as well.
 
  Like, after 1000 ms start with the loop of increase / decrease and
  inside the loop,
  every 100 ms, do an update. Once the loop get's its time-out, fire
  the change event, for the spinbox.
 
  does that make sense ?
 
  -M
 
  On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote:
   Is this a good idea?
  
   If the user wants to increase the counter 5 times, you would not want
   5 ajax calls for every time they click the up arrow.
  
   -Andrew
  
   On 9/21/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi guys,
   
I added a patch (and a comment) to TRINIDAD-729 (see [1]).
I am not sure if there is an issue with this fix/patch.
Do you mind to review it ?
   
Thanks!
Matthias
   
[1] https://issues.apache.org/jira/browse/TRINIDAD-729
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org

Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition

On 9/21/07, Simon Lessard [EMAIL PROTECTED] wrote:
 Hello Jeanne,

 I could live with that as long as the XSD should prevents the usage of both
 a bundle and a map at the same time. However, I would prefer a
 resource-bundle element than a translation-map. For one, it's much
 easier to create a ResourceBundle from a Map than the other way around.

It's easy enough to do either, but its not really a ResourceBundle instance
unless you can get it via ResourceBundle.getBundle().

IMO, the real point here is just saying let's get it from EL, instead of
loading a ResourceBundle ourselves, so it can be anything, ResourceBundle,
Map, we don't care.  So name the element translation-source perhaps?

-- Adam


 Also, that would be more aligned with JSF 1.2 since its include a way to
 define resource-bundle with a var name within the faces-config.xml.

 ~ Simon


 On 9/21/07, Jeanne Waldman  [EMAIL PROTECTED] wrote:
 
  Hi,
 
  I have a new issue I need to resolve and I wanted to run by my solution --
  https://issues.apache.org/jira/browse/TRINIDAD-728
  support for el to be used in a skin to bind to other translation data
 sources
 
  Currently, a SkinExtension and SkinAddition can have resource bundles
 associated with them so that a person can skin text.
  We have customers who want to use a Map that is EL-accessible instead of a
 ResourceBundle.
 
  I'd like to add a  'translation-map' element to the skin and
 skin-addition elements in trinidad-skins.xml.
  I'd add new constructors to SkinExtension and SkinAddition to accept a
 translationMap ValueExpression.
 
  Let me know what you think and if you think 'translation-map' is a good
 name for the new element.
  See below for an example.
 
  Thanks,
  Jeanne
 
  from trinidad-skins.xml:
  skin
  id
  purple.desktop
  /id
  family
  purple
  /family
  render-kit-id
  org.apache.myfaces.trinidad.desktop
  /render-kit-id
  style-sheet-name
  skins/purple/purpleSkin.css
  /style-sheet-name
  bundle-name
 
 org.apache.myfaces.trinidaddemo.resource.SkinBundle
  /bundle-name
  /skin
  !-- You can extend any skin you want. Here we want the purple
  skin, but with a bigger font size --
  skin
  id
  purpleBigFont.desktop
  /id
  family
  purpleBigFont
  /family
  extends
  purple.desktop
  /extends
  render-kit-id
  org.apache.myfaces.trinidad.desktop
  /render-kit-id
  style-sheet-name
  skins/purple/purpleBigFontSkin.css
  /style-sheet-name
  translation-map#{skinTranslationMap.contents}/translation-map
  /skin

Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition

On 9/21/07, Jeanne Waldman [EMAIL PROTECTED] wrote:



  Adam Winer wrote:
  On 9/21/07, Simon Lessard [EMAIL PROTECTED] wrote:


  Hello Jeanne,

 I could live with that as long as the XSD should prevents the usage of both
 a bundle and a map at the same time. However, I would prefer a
 resource-bundle element than a translation-map. For one, it's much
 easier to create a ResourceBundle from a Map than the other way around.

  It's easy enough to do either, but its not really a ResourceBundle instance
 unless you can get it via ResourceBundle.getBundle().

 IMO, the real point here is just saying let's get it from EL, instead of
 loading a ResourceBundle ourselves, so it can be anything, ResourceBundle,
 Map, we don't care. So name the element translation-source perhaps?

  Are you saying my ValueExpression should be an Object type instead of a Map
 type, and then for now I can
  accept Maps, but then as another enhancement I could accept
 ResourceBundles?
  It seems that it can't be anything, because I need to know what I am
 getting.

No, you actually can get anything.  Just use ELResolver.getValue()
to resolve the property.  That way, you have support for both
ResourceBundles and Maps with one element.

-- Adam




  -- Adam




  Also, that would be more aligned with JSF 1.2 since its include a way to
 define resource-bundle with a var name within the faces-config.xml.

 ~ Simon


 On 9/21/07, Jeanne Waldman  [EMAIL PROTECTED] wrote:


  Hi,

 I have a new issue I need to resolve and I wanted to run by my solution --
 https://issues.apache.org/jira/browse/TRINIDAD-728
 support for el to be used in a skin to bind to other translation data

  sources


  Currently, a SkinExtension and SkinAddition can have resource bundles

  associated with them so that a person can skin text.


  We have customers who want to use a Map that is EL-accessible instead of a

  ResourceBundle.


  I'd like to add a 'translation-map' element to the skin and

  skin-addition elements in trinidad-skins.xml.


  I'd add new constructors to SkinExtension and SkinAddition to accept a

  translationMap ValueExpression.


  Let me know what you think and if you think 'translation-map' is a good

  name for the new element.


  See below for an example.

 Thanks,
 Jeanne

 from trinidad-skins.xml:
  skin
  id
  purple.desktop
  /id
  family
  purple
  /family
  render-kit-id
  org.apache.myfaces.trinidad.desktop
  /render-kit-id
  style-sheet-name
  skins/purple/purpleSkin.css
  /style-sheet-name
  bundle-name


  org.apache.myfaces.trinidaddemo.resource.SkinBundle


  /bundle-name
  /skin
  !-- You can extend any skin you want. Here we want the purple
  skin, but with a bigger font size --
  skin
  id
  purpleBigFont.desktop
  /id
  family
  purpleBigFont
  /family
  extends
  purple.desktop
  /extends
  render-kit-id
  org.apache.myfaces.trinidad.desktop
  /render-kit-id
  style-sheet-name
  skins/purple/purpleBigFontSkin.css
  /style-sheet-name
  translation-map#{skinTranslationMap.contents}/translation-map
  /skin

Re: [TRINIDAD] New element in trinidad-skins.xml /SkinImpl/SkinAddition

-1 to trying to turn everything into ResourceBundle.  Just use EL -
ELResolver in 1.2, PropertyResolver in 1.1.  As of 1.2, that gives
you ResourceBundle and Map support.  In 1.1, only Map
(and bean, of course), but then again in 1.1 how do you get
unwrapped ResourceBundle instances into EL anyway?

@Gary:  the Shale LoadBundle class seems quite unnecessary
in 1.2, right?

-- Adam


On 9/21/07, Gary VanMatre [EMAIL PROTECTED] wrote:

 From: Simon Lessard [EMAIL PROTECTED]
 
 
 
 If we accept only a map, it's quite exclusive, unless we add yet another
 tag, but I would be -1 on that. However, as Adam suggested, we could call
 it translation-source and support both Map and ResourceBundle instances.
 We have to a very thin adapter Map -- ResourceBundle if a Map instance is
 passed and the remaining code will continue to work as it's now, with a
 ResourceBundle. 

 FWIW, Shale has a utility class that sounds very similar to what you have
 described [1].


 [1]
 http://svn.apache.org/viewvc/shale/framework/trunk/shale-core/src/main/java/org/apache/shale/util/LoadBundle.java?view=markup



 
 ~ Simon

 Gary

Re: [jira] Resolved: (TRINIDAD-731) xOffset/yOffset don't get correctly processed by plugins, switch to horzOffset/vertOffset for simplicity and clarity.

Yech, why don't we just fix the plugins???

-- Adam


On 9/21/07, Danny Robinson [EMAIL PROTECTED] wrote:
 Hard to say that they are breaking, because I'm not certain they ever worked
 ;-)

 I'll update the release notes to cover this though.

 D.


 On 9/21/07, Andrew Robinson [EMAIL PROTECTED] wrote:
  Is this a compatibility breaking change (meaning that the old
  attributes were removed)?
 
  If so, were are these items documented so that users know what happened?
 
  -Andrew
 
  On 9/21/07, Danny Robinson (JIRA)  dev@myfaces.apache.org wrote:
  
[
 https://issues.apache.org/jira/browse/TRINIDAD-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]
  
   Danny Robinson resolved TRINIDAD-731.
   -
  
  Resolution: Fixed
   Fix Version/s: 1.0.3-core
  
   Switched attribute names to horzOffset and vertOffset.
  
xOffset/yOffset don't get correctly processed by plugins, switch to
 horzOffset/vertOffset for simplicity and clarity.
   
 -
   
Key: TRINIDAD-731
URL:
 https://issues.apache.org/jira/browse/TRINIDAD-731
Project: MyFaces Trinidad
 Issue Type: Improvement
 Components: Components
   Affects Versions: 1.0.3-core
   Reporter: Danny Robinson
   Assignee: Danny Robinson
   Priority: Minor
Fix For: 1.0.3-core
   
   
  
  
   --
   This message is automatically generated by JIRA.
   -
   You can reply to this email to add a comment to the issue online.
  
  
 



 --
 Chordiant Software Inc.
 www.chordiant.com

Re: [Trinidad] - [IE] funny issue with form and defaultCommand

2007-09-20 Thread Adam Winer

OK, so looks like the issue is that for this submit,
we have:

var params = new Object();
params[src] = src;
params['source'] = src;

submitForm(frm,0,params);

We set params['source'] = src; to handle Trinidad buttons.
We set params[src] = src; to handle non-Trinidad buttons.

Then submitForm() has (with a lot of non-taken branches
snipped):

var hiddenField = form.elements[paramName];

 if (hiddenField.type == 'submit')
   // create an input type=hidden
 else
  hiddenField.value = paramValue;

I think we need to add a checkt to submitForm() that hiddenField is
not a button element too!

(BTW, Matthias:  glancing at Core.js, I noticed
we've got double copies of all the spinbox code!)

-- Adam


On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 reason is this

 script

 function changeValue(element)
 {
   element.value = element.id;
 }


 /script

 button id=foo onclick=changeValue(this);bar/button

 in FF, never the button-text is changed.

 -M

 On 9/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
  changed subject to better reflect the issue.
 
  -M
 
  On 9/20/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
   Hi,
  
   by accident I noticed this funny thing with form's defaultCommand and
   IE7 (true for IE 6 as well ??)
  
   here is a demo, that has a form, containing a defaultCommand
  
   http://www.irian.at/trinidad-demo/faces/components/form.jspx
  
   Do the following:
   -enter first value
   -enter second value AND! hit enter.
  
   = Notice that the button label changes to the ID of the button :-)
  
   (sure, FF it works as expected ;-))
  
   the source-code is:
   tr:form defaultCommand=first binding=#{editor.component}
   ...
 tr:inputText label=First form, First Field: shortDesc=Field 1 /
 tr:inputText label=First form, Second Field: shortDesc=Field 2 /
 tr:commandButton id=first text=First /
   ...
   /tr:form
  
   any comments ?
  
   -Matthias
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa

2007-09-20 Thread Adam Winer

I'm happier if we don't add any attributes...  We definitely
want default behavior where, if nothing is specified,
the icons get shown.

-- Adam


On 9/20/07, Jeanne Waldman [EMAIL PROTECTED] wrote:

  The other api I like is one you mentioned was not backwards compatible, and
 that is to have them put the icon in the facet if they want an icon.

  I agree that the below API is busy, but to me it is clear. No guessing what
 the logic is.


  Simon Lessard wrote:
 Hello Jeanne,

  Something alike was proposed at first, but again the most common usage
 kicks in. Such attributes imply, for GMail like behavior:

  tr:statusIndicator hideReadyIcon=true hideBusyIcon=true
f:facet name=busy
  tr:outputText value=Loading.../
/f:facet
  /tr:statusIndicator

  It's a bit longer, but it's easily livable with I guess.


 On 9/20/07, Jeanne Waldman [EMAIL PROTECTED] wrote:
 
  How about hideReadyIcon = true/false
  hideBusyIcon = true/false.
 
  It's explicit and the user doesn't have to guess at the logic we are using
 -- or read the doc.
 
  - Jeanne
 
 
  Simon Lessard wrote:
  Hello Adam,
 
 
  On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
   I think it should be as simple as for each of busy and
   ready, render the facet if it's present, the icon if it's not.
 
 
  The only issue with that behavior is most common usage. I think the most
 common usage with facets is going to be a busy facet and no ready (to
 mimic GMail behavior for example). Personally, that's the way I would use
 it. If that's really the most common case, then it should be as soon as a
 facet is specified, rendered or not, no icon will be rendered. But, if we
 think the most common case is going to be with both facets, then I agree
 with your suggestion.
 
  ~ Simon
 
 
   -- Adam
  
  
   On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
Hmm not as simple as I though. Before pushing a patch let decide on
 the
behavior for every use case:
   
Both facets are specified and rendered -- Don't render any icon
Both facets are specified but only one is rendered -- ?
 Both facets are specified but neither are rendered -- ?
 Only one facet is specified and rendered -- Don't render any icon or
render the icon of the missing facet?
Only one facet is specified but not rendered -- ?
No facet is specified -- Render both icons
   
~ Simon
   
   
On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
 Or put tr:icon in the facet. Yeah, that sound good too.



 On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  that sounds like the best solution.
 
  On 9/18/07, Adam Winer  [EMAIL PROTECTED]  wrote:
   IMO, if we have a facet, we don't render the icon.  No need
   for an attribute at all.
  
   Anyone that desperately needs both the facet and the icon
   can render two statusIndicators.
  
   -- Adam
  
  
   On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
Hi,
   
On 9/18/07, Simon Lessard  [EMAIL PROTECTED]  wrote:
 Speaking of which, I forgot to add skin documentation. I'll
 do
that right
 away.

 I would also like to add a new attribute to skip the icon
rendering. If it
 hasn't been of backward compatibility, I would have simply
 removed
them
   
I added a demo usage of the facet's, I was thinking, that it
shouldn't
render the default icon,
glad you pointed it out now.
   
 since it's easily doable with a combination of facet and
 tr:icon,
but since
 we had a release with the statusIndicator already, that's
 out of
question.
 So, what I need now is a decent attribute name. What do you
 think
of
 renderIcon or renderFacetsOnly?
   
I tend to like renderFacetsOnly, because that what you added
 where
facets.
   
Perhaps, we can change that soon, that when facet's are
 specified,
we
don't render the default icon.
   
-Matthias
   

 ~ Simon

   
   
--
Matthias Wessendorf
   
further stuff:
blog:
 http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog:
 http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org

Re: [TRINIDAD] PPR problem with 1.2.2 branch

PPR is totally overhauled from 1.2.1 to 1.2.2, so changes
aren't a surprise.  The question is why this is happening,
and we need more information, because we did (honest)
test this code quite a bit, so there's something different about
your set up, and ideally you could play around with a lot
of variables.

First up, are you really only using the RI?  No MyFaces
implementation also lying around on the classpath?  I'm
guessing this is Firefox?  Is this Facelets?  If so, what
version?  If JSP, is that really the full content of your page?
Are you using XHTML?  If so, is the problem specific
to XHTML (that is, does it go away if you build an
HTML page)?

-- Adam


On 9/18/07, Tobias Freier [EMAIL PROTECTED] wrote:


 Leonardo Uribe wrote:
 
  [Invalid PPR response. The response-headers were:\nServer:
  Apache-Coyote/1.1\nContent-Type: text/xml;ch...]
 
 I'm facing a similar error on my page.
 Tomcat 6.0.13 with Java 6 upd 2 and the newest version 1.2.2 of trinidad and
 RI jsf 1.2.4.

 trimmed jsf code:
 html xmlns=http://www.w3.org/1999/xhtml;
 f:view
 head
 /head
 trh:body id=a1
   tr:form id=form1
 tr:table id=table1 ...
   tr:column styleClass=mystyle
 h:outputText value=#{table.value} styleClass=boldText /
   /tr:column
 /tr:table
   /tr:form
 /trh:body
 /f:view
 /html

 So body, form and table have an id.
 When I try to change the range of the table or trigger any other event to
 update the tabele it doesn't work. The RangeChangeEvent method is executed
 but the page doesn't refresh. Instead I get the js error

 Invalid PPR response. The response-headers were:\nServer:
 Apache-Coyote/1.1\nX-Powered-By: JSF/1.2\nContent-Type:
 text/xml;charset=utf-8\nContent-Language: de\nTransfer-Encoding:
 chunked\nDate: Tue, 18 Sep 2007 23:45:14 GMT\n\n The invalid response
 was:\n?xml version=\1.0\ encoding=\UTF-8\
 ?\r\n\r\n\r\n\r\n\r\n\r\n\r\n!DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0
 Transitional//EN\
 \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
 xmlns=\http://www.w3.org/1999/xhtml\;\r\n?xml version=\1.0\
 ?\n?Tr-XHR-Response-Type ?\n...
 content to replace...

 The same code worked under trinidad 1.2.1
 Does anyone has a clue why it doesn't work with 1.2.2?

 Tnx, Tobias
 --
 View this message in context: 
 http://www.nabble.com/-TRINIDAD--PPR-problem-with-1.2.2-branch-tf4275649.html#a12768364
 Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa

I see what you're saying...  I think I'd be OK then with a rule
where specifying either facet gets rid of both icons.  Especially
with a bit of doc explaining why it does that (exactly the example
you give).

-- Adam



On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote:
 Hello Adam,

 On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
  I think it should be as simple as for each of busy and
  ready, render the facet if it's present, the icon if it's not.

 The only issue with that behavior is most common usage. I think the most
 common usage with facets is going to be a busy facet and no ready (to
 mimic GMail behavior for example). Personally, that's the way I would use
 it. If that's really the most common case, then it should be as soon as a
 facet is specified, rendered or not, no icon will be rendered. But, if we
 think the most common case is going to be with both facets, then I agree
 with your suggestion.

 ~ Simon


  -- Adam
 
 
  On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
   Hmm not as simple as I though. Before pushing a patch let decide on the
   behavior for every use case:
  
   Both facets are specified and rendered -- Don't render any icon
   Both facets are specified but only one is rendered -- ?
Both facets are specified but neither are rendered -- ?
Only one facet is specified and rendered -- Don't render any icon or
   render the icon of the missing facet?
   Only one facet is specified but not rendered -- ?
   No facet is specified -- Render both icons
  
   ~ Simon
  
  
   On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
Or put tr:icon in the facet. Yeah, that sound good too.
   
   
   
On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
 that sounds like the best solution.

 On 9/18/07, Adam Winer  [EMAIL PROTECTED]  wrote:
  IMO, if we have a facet, we don't render the icon.  No need
  for an attribute at all.
 
  Anyone that desperately needs both the facet and the icon
  can render two statusIndicators.
 
  -- Adam
 
 
  On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   Hi,
  
   On 9/18/07, Simon Lessard  [EMAIL PROTECTED]  wrote:
Speaking of which, I forgot to add skin documentation. I'll do
   that right
away.
   
I would also like to add a new attribute to skip the icon
   rendering. If it
hasn't been of backward compatibility, I would have simply
 removed
   them
  
   I added a demo usage of the facet's, I was thinking, that it
   shouldn't
   render the default icon,
   glad you pointed it out now.
  
since it's easily doable with a combination of facet and
 tr:icon,
   but since
we had a release with the statusIndicator already, that's out
 of
   question.
So, what I need now is a decent attribute name. What do you
 think
   of
renderIcon or renderFacetsOnly?
  
   I tend to like renderFacetsOnly, because that what you added
 where
   facets.
  
   Perhaps, we can change that soon, that when facet's are
 specified,
   we
   don't render the default icon.
  
   -Matthias
  
   
~ Simon
   
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org
  
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa

OK, five seconds more consideration, and now I'm torn.
It's easy enough to write:

  tr:statusIndicator
 f:facet name=busyLoading.../f:facet
 f:facet name=readytr:outputText//f:facet
  /tr:statusIndicator

... which would have the same effect.  So I could really
go either way.

-- Adam

On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote:
 I see what you're saying...  I think I'd be OK then with a rule
 where specifying either facet gets rid of both icons.  Especially
 with a bit of doc explaining why it does that (exactly the example
 you give).

 -- Adam



 On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote:
  Hello Adam,
 
  On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
   I think it should be as simple as for each of busy and
   ready, render the facet if it's present, the icon if it's not.
 
  The only issue with that behavior is most common usage. I think the most
  common usage with facets is going to be a busy facet and no ready (to
  mimic GMail behavior for example). Personally, that's the way I would use
  it. If that's really the most common case, then it should be as soon as a
  facet is specified, rendered or not, no icon will be rendered. But, if we
  think the most common case is going to be with both facets, then I agree
  with your suggestion.
 
  ~ Simon
 
 
   -- Adam
  
  
   On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
Hmm not as simple as I though. Before pushing a patch let decide on the
behavior for every use case:
   
Both facets are specified and rendered -- Don't render any icon
Both facets are specified but only one is rendered -- ?
 Both facets are specified but neither are rendered -- ?
 Only one facet is specified and rendered -- Don't render any icon or
render the icon of the missing facet?
Only one facet is specified but not rendered -- ?
No facet is specified -- Render both icons
   
~ Simon
   
   
On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
 Or put tr:icon in the facet. Yeah, that sound good too.



 On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
  that sounds like the best solution.
 
  On 9/18/07, Adam Winer  [EMAIL PROTECTED]  wrote:
   IMO, if we have a facet, we don't render the icon.  No need
   for an attribute at all.
  
   Anyone that desperately needs both the facet and the icon
   can render two statusIndicators.
  
   -- Adam
  
  
   On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
Hi,
   
On 9/18/07, Simon Lessard  [EMAIL PROTECTED]  wrote:
 Speaking of which, I forgot to add skin documentation. I'll do
that right
 away.

 I would also like to add a new attribute to skip the icon
rendering. If it
 hasn't been of backward compatibility, I would have simply
  removed
them
   
I added a demo usage of the facet's, I was thinking, that it
shouldn't
render the default icon,
glad you pointed it out now.
   
 since it's easily doable with a combination of facet and
  tr:icon,
but since
 we had a release with the statusIndicator already, that's out
  of
question.
 So, what I need now is a decent attribute name. What do you
  think
of
 renderIcon or renderFacetsOnly?
   
I tend to like renderFacetsOnly, because that what you added
  where
facets.
   
Perhaps, we can change that soon, that when facet's are
  specified,
we
don't render the default icon.
   
-Matthias
   

 ~ Simon

   
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
 
 
  --
  Matthias Wessendorf
 
  further stuff:
  blog: http://matthiaswessendorf.wordpress.com/
  mail: matzew-at-apache-dot-org

Re: [TRINIDAD] PPR problem with 1.2.2 branch

Ah, great, now we've got a compact description of the bug. :)
If you have an XML declaration, in the doc, we end up generating
two XML declarations on a PPR response.  There's code in Trinidad (in
the XmlOutput code) to strip anything before an XML declaration,
but it gets tripped up if there are two.

My understanding, backed up by:
http://en.wikipedia.org/wiki/XHTML#XML_Declaration
is that you don't need the XML declaration to be valid XHTML.

There is a clear error in your page, though:

contentType=text/html; charset=UTF-8

is wrong.  You need contentType=application/xhtml+xml; charset=UTF-8.
I'm not surprised your page wasn't rendered as XHTML.

That said, what you ideally should be doing in Trinidad is using
tr:document or trh:html/trh:head/trh:body, and not
specifying an XML declaration or DTD, but just letting Trinidad
do it for you.  These do support generating XHTML DTDs,
BTW, as long as you've set the contentType correctly.

-- Adam


On 9/19/07, Tobias Freier [EMAIL PROTECTED] wrote:

 Thanks for your help Adam,
 It doesn't work on Firefox or IE.
 I don't use Facelets. Just normal JSF with RI 1.2.04P02 and there is no
 MyFaces.
 No this was not the full page (too long). But thanks to your hint with the
 xhtml I found the error.

 The page started with:
 ?xml version=1.0 encoding=UTF-8 ?
 %@ taglib uri=http://java.sun.com/jsf/html; prefix=h %
 %@ taglib uri=http://java.sun.com/jsf/core; prefix=f %
 %@ taglib uri=http://myfaces.apache.org/trinidad; prefix=tr%
 %@ taglib uri=http://myfaces.apache.org/trinidad/html; prefix=trh%
 %@ page language=java contentType=text/html; charset=UTF-8
 pageEncoding=UTF-8%
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
 f:view
 head
 ...

 therefore the response of the PPR was

 ?xml version=1.0 encoding=UTF-8 ?
 !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
 http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
 html xmlns=http://www.w3.org/1999/xhtml;
 ?xml version=1.0 ?
 ?Tr-XHR-Response-Type ?
 content action=..

 Now I deleted the ?xml version=1.0 encoding=UTF-8 ? at the beginning
 of my JSP page and I get the response

 ?xml version=1.0 ?
 ?Tr-XHR-Response-Type ?
 content action=...

 this works fine now.
 The only problem is that this is no longer a well formed xhtml page.
 At this point I saw that my page isn't rendered as xhtml anyway. What do I
 have to use to get xhtml?

 Tobias



 Adam Winer wrote:
 
  PPR is totally overhauled from 1.2.1 to 1.2.2, so changes
  aren't a surprise.  The question is why this is happening,
  and we need more information, because we did (honest)
  test this code quite a bit, so there's something different about
  your set up, and ideally you could play around with a lot
  of variables.
 
  First up, are you really only using the RI?  No MyFaces
  implementation also lying around on the classpath?  I'm
  guessing this is Firefox?  Is this Facelets?  If so, what
  version?  If JSP, is that really the full content of your page?
  Are you using XHTML?  If so, is the problem specific
  to XHTML (that is, does it go away if you build an
  HTML page)?
 
  -- Adam
 
 
  On 9/18/07, Tobias Freier [EMAIL PROTECTED] wrote:
 
 
  Leonardo Uribe wrote:
  
   [Invalid PPR response. The response-headers were:\nServer:
   Apache-Coyote/1.1\nContent-Type: text/xml;ch...]
  
  I'm facing a similar error on my page.
  Tomcat 6.0.13 with Java 6 upd 2 and the newest version 1.2.2 of trinidad
  and
  RI jsf 1.2.4.
 
  trimmed jsf code:
  html xmlns=http://www.w3.org/1999/xhtml;
  f:view
  head
  /head
  trh:body id=a1
tr:form id=form1
  tr:table id=table1 ...
tr:column styleClass=mystyle
  h:outputText value=#{table.value} styleClass=boldText /
/tr:column
  /tr:table
/tr:form
  /trh:body
  /f:view
  /html
 
  So body, form and table have an id.
  When I try to change the range of the table or trigger any other event to
  update the tabele it doesn't work. The RangeChangeEvent method is
  executed
  but the page doesn't refresh. Instead I get the js error
 
  Invalid PPR response. The response-headers were:\nServer:
  Apache-Coyote/1.1\nX-Powered-By: JSF/1.2\nContent-Type:
  text/xml;charset=utf-8\nContent-Language: de\nTransfer-Encoding:
  chunked\nDate: Tue, 18 Sep 2007 23:45:14 GMT\n\n The invalid response
  was:\n?xml version=\1.0\ encoding=\UTF-8\
  ?\r\n\r\n\r\n\r\n\r\n\r\n\r\n!DOCTYPE html PUBLIC \-//W3C//DTD XHTML
  1.0
  Transitional//EN\
  \http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd\;\r\nhtml
  xmlns=\http://www.w3.org/1999/xhtml\;\r\n?xml version=\1.0\
  ?\n?Tr-XHR-Response-Type ?\n...
  content to replace...
 
  The same code worked under trinidad 1.2.1
  Does anyone has a clue why it doesn't work with 1.2.2?
 
  Tnx, Tobias
  --
  View this message in context:
  http://www.nabble.com/-TRINIDAD--PPR-problem-with-1.2.2-branch

Re: [Trinidad] Plugins 123 release ?

I think Andrew has some improvements for the Facelets
generator that would be really worthwhile.  Other than that,
I don't know of anything holding up the release.

-- Adam


On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

 not to bug you, but what are your takes on a release of the 1.2.3
 plugins. The unified one :-)

 -Matthias

 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa

On 9/19/07, Perkins, Nate-P63196 [EMAIL PROTECTED] wrote:
 Yes, but why pollute the page unnecessarily with an empty outputText?

Indeed.  (I'd probably use a tr:group, but same deal).

The flip side is wondering how much of a pain it'd be to
implement I want to change the ready icon, but not the busy icon
if we go with set either facet, both icons are gone.  Either design
makes someone's life hard...  which do we think is more common?

 If I approach the subject from a maintainability perspective, I think
 its more intuitive for the documentation to state why the icon is gone
 then to have to figure out why some developer stuck an empty outputText
 into a facet.

Anyone hacking in either case does have the option of
including a comment in the page, ya know!

-- Adam


 I've been watching this thread, so I hope you don't mind my 2 cents


 Nate Perkins
 General Dynamics C4 Systems

 This email message is for the sole use of the intended recipient(s) and
 may contain GDC4S
  confidential or privileged information. Any unauthorized review, use,
 disclosure or distribution
  is prohibited. If you are not an intended recipient, please contact
 the sender by reply email and
  destroy all copies of the original message.
 

 -Original Message-
 From: Adam Winer [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, September 19, 2007 9:24 AM
 To: MyFaces Development
 Subject: Re: svn commit: r576576 [1/3] - in
 /myfaces/trinidad/trunk/trinidad:
 trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components
 /trinidad/core/
 trinidad-impl/src/main/java/org/apache/myfaces/trinidadinternal/renderki
 t/core/xhtml/ trinida

 OK, five seconds more consideration, and now I'm torn.
 It's easy enough to write:

   tr:statusIndicator
  f:facet name=busyLoading.../f:facet
  f:facet name=readytr:outputText//f:facet
   /tr:statusIndicator

 ... which would have the same effect.  So I could really
 go either way.

 -- Adam

 On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote:
  I see what you're saying...  I think I'd be OK then with a rule
  where specifying either facet gets rid of both icons.  Especially
  with a bit of doc explaining why it does that (exactly the example
  you give).
 
  -- Adam
 
 
 
  On 9/19/07, Simon Lessard [EMAIL PROTECTED] wrote:
   Hello Adam,
  
   On 9/18/07, Adam Winer [EMAIL PROTECTED] wrote:
I think it should be as simple as for each of busy and
ready, render the facet if it's present, the icon if it's not.
  
   The only issue with that behavior is most common usage. I think the
 most
   common usage with facets is going to be a busy facet and no
 ready (to
   mimic GMail behavior for example). Personally, that's the way I
 would use
   it. If that's really the most common case, then it should be as
 soon as a
   facet is specified, rendered or not, no icon will be rendered. But,
 if we
   think the most common case is going to be with both facets, then I
 agree
   with your suggestion.
  
   ~ Simon
  
  
-- Adam
   
   
On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
 Hmm not as simple as I though. Before pushing a patch let decide
 on the
 behavior for every use case:

 Both facets are specified and rendered -- Don't render any icon
 Both facets are specified but only one is rendered -- ?
  Both facets are specified but neither are rendered -- ?
  Only one facet is specified and rendered -- Don't render any
 icon or
 render the icon of the missing facet?
 Only one facet is specified but not rendered -- ?
 No facet is specified -- Render both icons

 ~ Simon


 On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
  Or put tr:icon in the facet. Yeah, that sound good too.
 
 
 
  On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   that sounds like the best solution.
  
   On 9/18/07, Adam Winer  [EMAIL PROTECTED]  wrote:
IMO, if we have a facet, we don't render the icon.  No
 need
for an attribute at all.
   
Anyone that desperately needs both the facet and the icon
can render two statusIndicators.
   
-- Adam
   
   
On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED]
 wrote:
 Hi,

 On 9/18/07, Simon Lessard  [EMAIL PROTECTED] 
 wrote:
  Speaking of which, I forgot to add skin documentation.
 I'll do
 that right
  away.
 
  I would also like to add a new attribute to skip the
 icon
 rendering. If it
  hasn't been of backward compatibility, I would have
 simply
   removed
 them

 I added a demo usage of the facet's, I was thinking,
 that it
 shouldn't
 render the default icon,
 glad you pointed it out now.

  since it's easily doable with a combination of facet
 and
   tr:icon,
 but since
  we had a release with the statusIndicator already,
 that's out

Re: [Trinidad] Plugins 123 release ?

I think the big thing to test is making sure that the
1.0.3-SNAPSHOT core build runs fine against it.
We haven't been able to switch over our 1.0.3
build to the 1.2.3 plugins - the plugin snapshots
aren't getting deployed, so our build would break...

-- Adam


On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 cool,

 can you ping me, when you think it's fine ?

 I'd like to provide the RC over the weekend :-)

 .M

 On 9/19/07, Andrew Robinson [EMAIL PROTECTED] wrote:
  They are in. Barring some more testing, should be ready to go.
 
  On 9/19/07, Adam Winer [EMAIL PROTECTED] wrote:
   I think Andrew has some improvements for the Facelets
   generator that would be really worthwhile.  Other than that,
   I don't know of anything holding up the release.
  
   -- Adam
  
  
   On 9/19/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Hi,
   
not to bug you, but what are your takes on a release of the 1.2.3
plugins. The unified one :-)
   
-Matthias
   
--
Matthias Wessendorf
   
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
mail: matzew-at-apache-dot-org
   
  
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

[jira] Created: (TOBAGO-490) How can to make hyperlink on tc:menu

2007-09-18 Thread adam (JIRA)

How can to make hyperlink on tc:menu
--

 Key: TOBAGO-490
 URL: https://issues.apache.org/jira/browse/TOBAGO-490
 Project: MyFaces Tobago
  Issue Type: Wish
Reporter: adam


Dear all ;

i want to know How can i make hyperlink on tc:menu becouse i don't need to 
use tc:menuItem .

Thanks  Regards 
M.adam

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOBAGO-492) How can to make hyperlink on tc:menu

2007-09-18 Thread adam (JIRA)

How can to make hyperlink on tc:menu
--

 Key: TOBAGO-492
 URL: https://issues.apache.org/jira/browse/TOBAGO-492
 Project: MyFaces Tobago
  Issue Type: New Feature
Reporter: adam


Dear all ;

i want to know How can i make hyperlink on tc:menu becouse i don't need to 
use tc:menuItem .

Thanks  Regards 
M.adam

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (TOBAGO-493) How can i make hyperlink on tc:menu

2007-09-18 Thread adam (JIRA)

How can i make hyperlink on tc:menu 
--

 Key: TOBAGO-493
 URL: https://issues.apache.org/jira/browse/TOBAGO-493
 Project: MyFaces Tobago
  Issue Type: Improvement
Reporter: adam


Dear all ;

i want to know How can i make hyperlink on tc:menu becouse i don't need to 
use tc:menuItem .

Thanks  Regards 
M.adam

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa

IMO, if we have a facet, we don't render the icon.  No need
for an attribute at all.

Anyone that desperately needs both the facet and the icon
can render two statusIndicators.

-- Adam


On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

 On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
  Speaking of which, I forgot to add skin documentation. I'll do that right
  away.
 
  I would also like to add a new attribute to skip the icon rendering. If it
  hasn't been of backward compatibility, I would have simply removed them

 I added a demo usage of the facet's, I was thinking, that it shouldn't
 render the default icon,
 glad you pointed it out now.

  since it's easily doable with a combination of facet and tr:icon, but since
  we had a release with the statusIndicator already, that's out of question.
  So, what I need now is a decent attribute name. What do you think of
  renderIcon or renderFacetsOnly?

 I tend to like renderFacetsOnly, because that what you added where facets.

 Perhaps, we can change that soon, that when facet's are specified, we
 don't render the default icon.

 -Matthias

 
  ~ Simon
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: Continuum

Yes, please!  +1.

-- Adam


On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 +1

 we really need a thing like that :-)

 On 9/18/07, Bernd Bohmann [EMAIL PROTECTED] wrote:
  Hello Matthias,
 
  my current plan is to setup an continuum instance on 8080 again, for the
  deploy and nightly build stuff.
 
  Any objections?
 
  Regards
 
 
  Bernd
 
  Matthias Wessendorf wrote:
   Hi,
  
   there was a continuum server (port 8081) on our zone, currently down.
   The vmbuild, I can't deploy stuff, does only build...
  
   What is the current plan, do we want to move all our projects to
   Brett's vmbuild ?
  
   -Matze
  
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa

I think it should be as simple as for each of busy and
ready, render the facet if it's present, the icon if it's not.

-- Adam


On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
 Hmm not as simple as I though. Before pushing a patch let decide on the
 behavior for every use case:

 Both facets are specified and rendered -- Don't render any icon
 Both facets are specified but only one is rendered -- ?
  Both facets are specified but neither are rendered -- ?
  Only one facet is specified and rendered -- Don't render any icon or
 render the icon of the missing facet?
 Only one facet is specified but not rendered -- ?
 No facet is specified -- Render both icons

 ~ Simon


 On 9/18/07, Simon Lessard [EMAIL PROTECTED] wrote:
  Or put tr:icon in the facet. Yeah, that sound good too.
 
 
 
  On 9/18/07, Matthias Wessendorf  [EMAIL PROTECTED] wrote:
   that sounds like the best solution.
  
   On 9/18/07, Adam Winer  [EMAIL PROTECTED] wrote:
IMO, if we have a facet, we don't render the icon.  No need
for an attribute at all.
   
Anyone that desperately needs both the facet and the icon
can render two statusIndicators.
   
-- Adam
   
   
On 9/18/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
 Hi,

 On 9/18/07, Simon Lessard  [EMAIL PROTECTED] wrote:
  Speaking of which, I forgot to add skin documentation. I'll do
 that right
  away.
 
  I would also like to add a new attribute to skip the icon
 rendering. If it
  hasn't been of backward compatibility, I would have simply removed
 them

 I added a demo usage of the facet's, I was thinking, that it
 shouldn't
 render the default icon,
 glad you pointed it out now.

  since it's easily doable with a combination of facet and tr:icon,
 but since
  we had a release with the statusIndicator already, that's out of
 question.
  So, what I need now is a decent attribute name. What do you think
 of
  renderIcon or renderFacetsOnly?

 I tend to like renderFacetsOnly, because that what you added where
 facets.

 Perhaps, we can change that soon, that when facet's are specified,
 we
 don't render the default icon.

 -Matthias

 
  ~ Simon
 


 --
 Matthias Wessendorf

 further stuff:
 blog: http://matthiaswessendorf.wordpress.com/
 mail: matzew-at-apache-dot-org

   
  
  
   --
   Matthias Wessendorf
  
   further stuff:
   blog: http://matthiaswessendorf.wordpress.com/
   mail: matzew-at-apache-dot-org

Re: svn commit: r576576 [1/3] - in /myfaces/trinidad/trunk/trinidad: trinidad-build/src/main/resources/META-INF/maven-faces-plugin/components/trinidad/core/ trinidad-impl/src/main/java/org/apache/myfa