from:"Matt Cooper"

[jira] [Updated] (TRINIDAD-2457) Servlet external context wrapper missing JSF 2 API

2014-03-03 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-2457:
--

   Resolution: Fixed
Fix Version/s: 2.1.1-core
 Assignee: Matt Cooper
   Status: Resolved  (was: Patch Available)

Thanks to Gary van Matre for the patch.

 Servlet external context wrapper missing JSF 2 API
 --

 Key: TRINIDAD-2457
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2457
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.1.1-core
 Environment: generic
Reporter: Gary VanMatre
Assignee: Matt Cooper
 Fix For: 2.1.1-core

 Attachments: ServletExternalContext.java.patch


 The  ServletExternalContext is created prior to the JSF lifecycle.  JSF 2 
 added the setResponseHeader API to the external context.  New code was 
 introduced that calls on this API prior to being dispatched to the faces 
 servlet resulting in an exception.



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

Re: [VOTE] Release of Apache MyFaces Trinidad 2.1.0

2013-11-18 Thread Matt Cooper

+1


On Mon, Nov 18, 2013 at 11:46 AM, jeanne waldman
jeanne.wald...@oracle.comwrote:

  compiled and ran a test
 +1

 On 11/18/2013 10:44 AM PT, Scott O'Bryan wrote:

 +1
 --
 Scott O'Bryan

 On November 18, 2013 at 8:25:37 AM, Max Starets 
 (max.star...@oracle.com//max.star...@oracle.com)
 wrote:

  +1
 On 11/15/2013 4:02 PM, Scott O'Bryan wrote:

  Hello everyone,

  I was running the tasks needed to release Apache MyFaces Trinidad v.
 2.1.0 which is the latest in the Trinidad render kit series.  This is the
 first release in over a year and contains over a hundred bug fixes since
 the last release.  All Blocker bugs are currently fixed and all patches
 request by the community have been applied.  All tests are passing as is
 the apache-rat:check.

  I have generated the tag [1] and have deployed the build artifacts to
 nexus [2].  I have also included the source archive [3].  Please take a
 look at the Apache MyFaces Trinidad v. 2.1.0 release artifacts and vote.

  Please note:
  This vote is majority approval with a minimum of three +1 votes (see
 [4]).

 
 [ ] +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,
   Scott O'Bryan

  [1] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.1.0
 [2]
 https://repository.apache.org/content/repositories/orgapachemyfaces-141
 [3]
 https://repository.apache.org/content/repositories/orgapachemyfaces-141/org/apache/myfaces/trinidad/trinidad/2.1.0/trinidad-2.1.0-source-release.zip
 [4] http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: Wiki Spam

2013-04-23 Thread Matt Cooper

Thank you Mike for getting this going!


On Tue, Apr 23, 2013 at 8:32 AM, Mike Kienenberger mkien...@gmail.comwrote:

 I've requested Infra to help us make this happen.

 https://issues.apache.org/jira/browse/INFRA-6191

 On Mon, Apr 22, 2013 at 10:04 AM, Mike Kienenberger mkien...@gmail.com
 wrote:
  So I've been poking around for a while to try to set up
  AdminGroup/ContributorsGroup, and I know what the pages should look
  like.
 
  But I don't currently have the permissions to make the changes myself.
 
  http://wiki.apache.org/general/HowToBeWikiAdministrator
 
  Does anyone here already have Wiki Administrator permissions?
 
  Or apsite permission on minotaur?
 
  If not, I'll need to contact infrastructure.
 
  On Fri, Apr 19, 2013 at 4:19 PM, Mike Kienenberger mkien...@gmail.com
 wrote:
  My recommendation is that we set up an AdminGroup, probably with all
  committers in it.
 
  Then we add additional people to the ContributorsGroup as desired.
 
 
  http://wiki.apache.org/general/WikiFrequentlyAskedQuestions
 
  http://wiki.apache.org/general/OurWikiFarm
  =
  per wiki access control - tighten your wiki just a little, benefit just
 a lot
 
  Long sub-title for a fairly long subject.
 
  The MoinMoin wiki is very configurable, more so than some might think.
  Of course, wikis are meant to be open, for complete and utter open
  collaboration. That is appreciated. However, there are some that would
  like a balance between open wiki and having to spend time cleaning up
  spam each week. Times change, and the reality is, spammers are here
  and in greater numbers than before. What can we do? Well, here is a
  suggestion - and one that can be easily implemented and takes but 2
  minutes (for infra) to set up.
 
  Have your project wiki editable only by a custom trusted group - that
  need not be committers only - it can in fact still be anybody who
  wants to edit your wiki, they just need to ask one time for edit
  access and thats it. Is this an incovenience? To ask once for access,
  I don't think so. After all as a potential contributor to your wiki
  you (project) will already be conversing with the potential
  contributor via the mailing lists right? How much pain is it to add
  someone to the custom trusted group once it has been set up? , no pain
  at all, a member of the projects AdminGroup edits one wiki page, adds
  the users WikiuserName to the bottom of the list and save the page! 10
  seconds maybe and your done. For the amount of times you will have to
  do that as opposed to the amount of times you spend cleaning up spam -
  you work out which is better.
 
  The spamassassin wiki is a good example - those in the project wikis
  AdminGroup can add folks to the projects ContributorsGroup and that's
  it. How much spam has spamassassin received since this was setup ?
  Zero, Zilch, Nil, Nada.
 
  Remember also, any page can have its own access control which
  overrides and per wiki and per farm defaults - This page does just
  that, as does LocalBadContent and BadContent pages.
  =
 
 
 
  On Fri, Apr 19, 2013 at 3:47 PM, Mike Kienenberger mkien...@gmail.com
 wrote:
  Probably it's time to enable some kind of protection for the wiki.
 
  I've been hoping to avoid that, but the amount of spam the past two
  weeks has finally exceeded my willingness to continue fixing by hand.
 
  Is anyone who is subscribed to infrastructure willing to look into
  this?   If no takers, I guess I'll sign up and see what can be done.
 
 
  On Fri, Apr 19, 2013 at 3:41 PM, Cagatay Civici
  cagatay.civ...@gmail.com wrote:
  Hi,
 
  Does anyone know how can I unsubscribe from wiki as it is full of spam
  everyday.
 
  Thanks,
 
  Cagatay Civici
  PrimeFaces Lead
  www.primefaces.org

Re: Updating the homepage...

2013-03-12 Thread Matt Cooper

Maybe we just need to ask the spammers who keep adding pages to our wiki ;)

On Tue, Mar 12, 2013 at 11:59 AM, Grant Smith gr...@marathonpm.com wrote:

 Udo,

 I tried to do that a few months ago. Do we have documentation somewhere on
 how to update the homepage ?

 Thanks,
 -Grant.


 On Tue, Mar 12, 2013 at 8:19 AM, Udo Schnurpfeil u...@schnurpfeil.dewrote:

 Hi,

 I've updated some information on the team-list and want to release that.

 If you also have some changes to do, you may want to commit that, so we
 can update the homepage in the next days.

 Regards

 Udo




 --
 Grant Smith - V.P. Information Technology
 Marathon Computer Systems, LLC.

[jira] [Updated] (TRINIDAD-2306) Use the trident version to detect the IE browser if available in the user agent string

2012-11-29 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-2306:
--

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

Patches applied to:
trunk - r1378677
2.0.0.x-branch - r1415345

 Use the trident version to detect the IE browser if available in the user 
 agent string
 --

 Key: TRINIDAD-2306
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2306
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.1.0-core
Reporter: Gary VanMatre
 Fix For: 2.1.0-core

 Attachments: trinidad-IE-compat-override-2.x.patch, 
 trinidad-IE-compat-override.patch


 Starting with IE8, the trident version in the user agent string is a more 
 reliable way of detecting the maximum capabilities of the browser.  The 
 browser version string often defaults to IE7 when in compatibility mode or 
 using the IE WebBrowser component.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2337) Typo in ListView component meta-data

2012-11-05 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-2337:
--

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

 Typo in ListView component meta-data
 

 Key: TRINIDAD-2337
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2337
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.2-core
Reporter: Venkata Guddanti
 Fix For: 2.1.0-core

 Attachments: lv-metadata.patch

   Original Estimate: 2h
  Remaining Estimate: 2h

 The meta-data for the new ListView component had typo in the event parameters 
 for the method expression. The event parameter for selectionListener and the 
 groupDisclosureListener has this type. Because of this ListView component 
 implementations will fail during jsp compilation for selectionListener and 
 groupDisclosureListener.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: Move Trinidad Trunk to JSF 2.1

2012-03-26 Thread Matt Cooper

+1

On Mon, Mar 26, 2012 at 8:42 AM, gabrielle.crawf...@oracle.com wrote:

 +1



 On Mar 25, 2012, at 9:17 AM, Scott O'Bryan darkar...@gmail.com wrote:

  Hey all,
 
  Currently the Trinidad Trunk is set to JSF 2.0.  There have been a
 number of blocker bugs recently (namely some issues with the
 ViewDeclarationLanguages and composite components) which have generated
 some blocking bugs.  These problems were cause by additional methods in the
 ViewDeclarationLanguage syntax which we have to wrap for some of the
 functionality in Trinidad to be complete.
 
  At this time I propose the following:
 
  1. Copy the current Trinidad Trunk to be branches/trinidad-2.0.x
  2. Change the version of Trinidad Trunk to be 2.1.0-SNAPSHOT
  3. Change the JSF dependency for trunk to be MyFaces 2.1
  4. Change the trinidad plugins trunk to be 2.1.0 for consistency.
  5. Change both branches/trinidad-2.0.x and trunk to use the new trinidad
 plugins snapshot.
 
  I'm hoping everyone will agree to this so that we can fix some of the
 blocker issues we've had show up after the the last Trinidad release.  Many
 of which seem to be JSF 2.1 related.
 
  Please respond to this email with a +1 or a -1 and don't forget to
 include any any reasons why you do not wish to support the move.
 
  Thanks,
   Scott

Re: [VOTE] Trinidad 2.0.1 (try 2)

2012-02-27 Thread Matt Cooper

On Sat, Feb 25, 2012 at 7:46 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:

-- Blake Sullivan

On Feb 25, 2012, at 3:36 AM, Andy Schwartz wrote:

+1.

Thanks for putting this together Scott.

Andy

On Feb 24, 2012, at 12:30 PM, Scott O'Bryan darkar...@gmail.com wrote:

Hi Everyone,

I was running the tasks needed to get the Trinidad 2.0.1 release out and
now I need a vote as to whether everything looks good or not. I have
committed most of the most recent submitted patches and things look to be
fairly stable. There are a few patches outstanding, but I wanted to put
those into trunk so that they can get some more testing.

This is a very big release with many bug fixes and quite a few fixes to
support the MyFaces checkstyle audits. You will notice the absence of the
component showcase example module. It was decided to remove this module
because it contains code brought in by Maven which is NOT under the Apache
license. The component showcase **IS** available by building the source
manually.

The last vote was vetoed because some files were missing licenses and
there were some references to external repositories. The new staging
repositories contain fixes for all of these issues including an enhancement
to the base POM file which will automatically run the rat verifications at
build to prevent the licensing issues in the future.

At this time, I would like to ask for a vote, once again, on this
release. All of the following should be ready for review:

* The generated repository and assembly artifacts [1]
* The generated source archive [2]
* The updated svn repository [3]

Please review the artifacts and vote according to the following:

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

This vote will remain open for at least 72 hours.

Thanks,
Scott O'Bryan

[1]
https://repository.apache.org/content/repositories/orgapachemyfaces-005/
https://repository.apache.org/content/repositories/orgapachemyfaces-067
[2]
https://repository.apache.org/content/repositories/orgapachemyfaces-005/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip
https://repository.apache.org/content/repositories/orgapachemyfaces-067/org/apache/myfaces/trinidad/trinidad/2.0.1/trinidad-2.0.1-source-release.zip
[3]
https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/
https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.1/

[jira] [Updated] (TRINIDAD-2212) JDev plugin could use some improvements

2012-02-08 Thread Matt Cooper (Updated) (JIRA)


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

Matt Cooper updated TRINIDAD-2212:
--

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

 JDev plugin could use some improvements
 ---

 Key: TRINIDAD-2212
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2212
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions: 2.0.7-plugins
 Environment: All
Reporter: Bud Osterberg
Priority: Minor
 Fix For: 2.0.8-plugins

 Attachments: jdevjdev.patch

   Original Estimate: 48h
  Remaining Estimate: 48h

 There have been some improvements requested for the jdev:jdev plugin
 e.g. Allow the exclusion of certain projects from the workspace, allow 
 specific naming of the context root or the workspace itself, etc.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] (TRINIDAD-1041) - Please commit

2012-01-12 Thread Matt Cooper

Done: 1230628.

Thank you,
Matt

On Thu, Jan 12, 2012 at 1:07 AM, Anand Nath anand.v.n...@oracle.com wrote:

 Hello,

 Can someone review and commit the patch uploaded to TRINIDAD-1041 to
 1.2.12.6.2 branch?

 Thanks
 Anand

[jira] [Updated] (TRINIDAD-2170) There is no way to specify a real pseudo element in a skin css.

2011-12-22 Thread Matt Cooper (Updated) (JIRA)


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

Matt Cooper updated TRINIDAD-2170:
--

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

 There is no way to specify a real pseudo element in a skin css.
 ---

 Key: TRINIDAD-2170
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2170
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.0.0-core
 Environment: any
Reporter: Mark Yvanovich
 Fix For: 2.0.1-core

 Attachments: TRINIDAD-2170_1.2.12.6.2-branch.patch, 
 TRINIDAD-2170_trunk.patch

   Original Estimate: 72h
  Remaining Estimate: 72h

 If you need a real css pseudo element rendered to the generated css, there is
 currently no way to do this.  The :: sequence will always be replaced with a
 _.  For example, to be able to skin the placeholder text in FF, you would
 specify:
 af|inputText::content::-moz-placeholder {}
 The generated selector needs to be:
 af_inputText_content::-moz-placeholder {}
 Currently, the generated CSS will output:
 af_inputText_content_-moz-placeholder {}
 One solution would be to have a whilelist of pseudo elements that we should
 render as is rather than replace the '::' with a '_'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release of Trinidad Maven Plugins v. 2.0.7

2011-12-20 Thread Matt Cooper

+1

On Mon, Dec 19, 2011 at 4:00 PM, Dave Robinson drmaill...@gmail.com wrote:

 +1


 On Mon, Dec 19, 2011 at 3:54 PM, Scott O'Bryan darkar...@gmail.comwrote:

  Hello Everyone,

 I was running the tasks needed to get the Trinidad Maven Plugins v. 2.0.7
 released and now I need a vote as to whether everything looks good or not.
 There were some minor fixes and the plugins including adding support
 marking deprecated tag in tag documentation and the removal of some
 system.out's that made the plugin overly verbose.  This tag is needed for
 the upcoming Trinidad release.

 I have generated the tag and deployed all the artifacts to the Nexus
 Repository for review.  The artifacts are as follows:

 * The generated repository artifacts [1]
 * The updated svn repository [2]

 Please take a look at the artifacts and don't forget to vote early and
 often.  :D  The vote will stay open for at least 72 hours to give people a
 chance to respond.

 Thanks,
   Scott O'Bryan

 [1] https://repository.apache.org/content/repositories/orgapachemyfaces-004
 https://repository.apache.org/content/repositories/orgapachemyfaces-372/
 [2]
 https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.7https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6

[jira] [Resolved] (TRINIDAD-2140) add a new ouput-mode for offline content

2011-12-19 Thread Matt Cooper (Resolved) (JIRA)


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

Matt Cooper resolved TRINIDAD-2140.
---

   Resolution: Fixed
Fix Version/s: 2.0.1-core

 add a new ouput-mode for offline content 
 -

 Key: TRINIDAD-2140
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2140
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 1.2.16-core, 2.0.1-core
Reporter: Pavitra Subramaniam
 Fix For: 2.0.1-core

 Attachments: JIRA-2140-12.6.2-12082011.patch, 
 JIRA-2140-12162011-trunk.patch, jira2140-10262011.patch


 Introduce a new output-mode called 'offline' that will be useful when 
 rendering content for offline viewing. In this mode the components may render 
 content with more client side interactivity in mind. This mode is useful when 
 rendering pages as attachments to emails, for example. A user receiving an 
 email can open the attachment when they are not connected to a network. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2141) add a new 'browser-generic' agent

2011-12-19 Thread Matt Cooper (Updated) (JIRA)


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

Matt Cooper updated TRINIDAD-2141:
--

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

 add a new 'browser-generic' agent 
 --

 Key: TRINIDAD-2141
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2141
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 1.2.15-core , 2.0.1-core
Reporter: Pavitra Subramaniam
 Fix For: 2.0.1-core

 Attachments: JIRA-2141-12.6.2-12082011.patch, 
 JIRA-2141-12162011-trunk.patch, JIRA2141 - 09282011.patch, JIRA2141 - 
 10032011.patch, JIRA2141.patch


 It would be very useful to have an agent called - 'browser-generic', which 
 represents the lowest common denominator agent for all browsers. 
 We also would want this to have its own capabilities that any generic browser 
 agent supports today. 
 This agent would be very useful in usecases where the user agent cannot be 
 determined at the time of rendering. 
 For example when rendering content for a page to be used as a file attachment 
 in an email, this could be very useful.
 CSS rules with @agent keyword would be ignored. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2137) Improve Trinidad component and tagdoc generation plugin to handle deprecated classes

2011-12-09 Thread Matt Cooper (Updated) (JIRA)


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

Matt Cooper updated TRINIDAD-2137:
--

Resolution: Fixed
Status: Resolved  (was: Patch Available)

 Improve Trinidad component and tagdoc generation plugin to handle deprecated 
 classes
 

 Key: TRINIDAD-2137
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2137
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Documentation
Affects Versions: 2.0.6-plugins
Reporter: Dave Robinson
Priority: Minor
 Attachments: trinidadMaven2.0.xJIRA2137.patch, 
 trinidadMavenTrunkJIRA2137.patch


 When creating component metadata, a component may be marked as deprecated 
 using fmd:deprecated. When a component is deprecated, we should include 
 this information in the generated class javadoc, as well as in the generated 
 tagdoc page.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2179) css processing fails without warning when selector misses end braces

2011-12-09 Thread Matt Cooper (Updated) (JIRA)


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

Matt Cooper updated TRINIDAD-2179:
--

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

 css processing fails without warning when selector misses end braces
 

 Key: TRINIDAD-2179
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2179
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.0.2-core
Reporter: Anand V Nath
Priority: Minor
 Fix For: 2.0.1-core

 Attachments: bug-12583411-fin.patch


 Skinning framework processes CSS file having syntax errors without logging 
 any warning. All style class definitions beyond this erroneous entry fails 
 the processing. 
 This bug is to ask that our skinning framework detects this situation at 
 runtime and warns in the log.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-1813) partialSubmit attribute not working for command button when try to open dialog box

2011-12-09 Thread Matt Cooper (Updated) (JIRA)

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

Matt Cooper updated TRINIDAD-1813:
--

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

partialSubmit attribute not working for command button when try to open
dialog box
--

Key: TRINIDAD-1813
URL: https://issues.apache.org/jira/browse/TRINIDAD-1813
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 2.0.0-alpha
Environment: Window XP, java 6, Eclipse 3.4.2, Tomcat 6
Reporter: Navnath Kumbhar
Assignee: Scott O'Bryan
Priority: Blocker
Fix For: 2.0.2-core

Attachments: PartialViewContextImpl.patch

Hi There,
I am trying to implement one simple functionality as shown in live Trinidad
demo of Dialog box. Click on button, get value of from parent window to
dialog box, change value from dialog box and submit it, then submitted value
should get reflected on parent window's field.
I am getting value from dialog box but at code level. But when I try to set
that value to display on page it's not reflecting. and ask me to reload page.
when I reload page then again dialog box is there.
This is happen when I remove partialSubmit=true from button attribute. when
I place this attribute, then there is no any error, but dialog is not
appearing.
Please Please let me know how do I open dialog box using command button with
setting partialSubmit=true attribute?
Is this version problem.
I am stuck on this issue from last 2 Months. still don't have any solution.
Is Trinidad really implement Dialog box as they have shown on demo site? If
Yes, then why all downloaded code is working fine only except DIALOG BOX?
Please replay to this post. Any kind of suggestion is welcome.
Thank You,
Navnath Kumbhar.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TRINIDAD-2170) There is no way to specify a real pseudo element in a skin css.

2011-12-02 Thread Matt Cooper (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161850#comment-13161850
 ] 

Matt Cooper commented on TRINIDAD-2170:
---

I haven't tried it yet but I wonder if it also has trouble with CSS3 the 
various keyframe animation @-blocks and nested style blocks, e.g.:

@keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

@-moz-keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

@-webkit-keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

 There is no way to specify a real pseudo element in a skin css.
 ---

 Key: TRINIDAD-2170
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2170
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.0.0-core
 Environment: any
Reporter: Mark Yvanovich
   Original Estimate: 72h
  Remaining Estimate: 72h

 If you need a real css pseudo element rendered to the generated css, there is
 currently no way to do this.  The :: sequence will always be replaced with a
 _.  For example, to be able to skin the placeholder text in FF, you would
 specify:
 af|inputText::content::-moz-placeholder {}
 The generated selector needs to be:
 af_inputText_content::-moz-placeholder {}
 Currently, the generated CSS will output:
 af_inputText_content_-moz-placeholder {}
 One solution would be to have a whilelist of pseudo elements that we should
 render as is rather than replace the '::' with a '_'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Issue Comment Edited] (TRINIDAD-2170) There is no way to specify a real pseudo element in a skin css.

2011-12-02 Thread Matt Cooper (Issue Comment Edited) (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161850#comment-13161850
 ] 

Matt Cooper edited comment on TRINIDAD-2170 at 12/2/11 8:56 PM:


I haven't tried it yet but I wonder if it also has trouble with the various 
CSS3 keyframe animation @-blocks and nested style blocks, e.g.:

@keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

@-moz-keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

@-webkit-keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

  was (Author: mattcooper):
I haven't tried it yet but I wonder if it also has trouble with CSS3 the 
various keyframe animation @-blocks and nested style blocks, e.g.:

@keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

@-moz-keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}

@-webkit-keyframes mymove {
  0%   { top: 10px;  background-color: red; }
  50%  { top: 100px; background-color: green; }
  100% { top: 500px; background-color: blue; }
}
  
 There is no way to specify a real pseudo element in a skin css.
 ---

 Key: TRINIDAD-2170
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2170
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.0.0-core
 Environment: any
Reporter: Mark Yvanovich
   Original Estimate: 72h
  Remaining Estimate: 72h

 If you need a real css pseudo element rendered to the generated css, there is
 currently no way to do this.  The :: sequence will always be replaced with a
 _.  For example, to be able to skin the placeholder text in FF, you would
 specify:
 af|inputText::content::-moz-placeholder {}
 The generated selector needs to be:
 af_inputText_content::-moz-placeholder {}
 Currently, the generated CSS will output:
 af_inputText_content_-moz-placeholder {}
 One solution would be to have a whilelist of pseudo elements that we should
 render as is rather than replace the '::' with a '_'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2175) Ensure that skin files can house CSS3 keyframe animations

2011-12-02 Thread Matt Cooper (Created) (JIRA)

Ensure that skin files can house CSS3 keyframe animations
-

 Key: TRINIDAD-2175
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2175
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Reporter: Matt Cooper


After seeing TRINIDAD-2107, it got me thinking about CSS3 keyframe animations.  
I have not tested it but I suspect it suffers from the same kind of issue 
described in 2107 because @keyframes is not a previously-known @-rule so 
Trinidad might choke on it and the new syntax for the nested style blocks with 
% or named (e.g. from/to) prefixes may fail parsing and probably don't 
support skinning aliases and variables.  (One final note... my-move should 
not be compressed into a new name because it can be used by other inlineStyles 
or style blocks.)

Here's some example styling to test if it passes through to generation:

@keyframes my-move { 
  0% { top: 10px; background-color: red; } 
  50% { top: 100px; background-color: green; } 
  100% { top: 500px; background-color: blue; } 
} 

@-moz-keyframes my-move { 
  0% { top: 10px; background-color: red; } 
  50% { top: 100px; background-color: green; } 
  100% { top: 500px; background-color: blue; } 
} 

@-webkit-keyframes my-move { 
  0% { top: 10px; background-color: red; } 
  50% { top: 100px; background-color: green; } 
  100% { top: 500px; background-color: blue; } 
}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (TRINIDAD-2170) There is no way to specify a real pseudo element in a skin css.

2011-12-02 Thread Matt Cooper (Commented) (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13161868#comment-13161868
 ] 

Matt Cooper commented on TRINIDAD-2170:
---

Sure, no problem... filed TRINIDAD-2175:
- support for the keyframe, -moz-keyframe, -webkit-keyframe, etc. @-block 
notation
- support for nested style block syntax in the %/from/to keyframe definitions
- support for aliases and variables in those nested blocks

 There is no way to specify a real pseudo element in a skin css.
 ---

 Key: TRINIDAD-2170
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2170
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions: 2.0.0-core
 Environment: any
Reporter: Mark Yvanovich
   Original Estimate: 72h
  Remaining Estimate: 72h

 If you need a real css pseudo element rendered to the generated css, there is
 currently no way to do this.  The :: sequence will always be replaced with a
 _.  For example, to be able to skin the placeholder text in FF, you would
 specify:
 af|inputText::content::-moz-placeholder {}
 The generated selector needs to be:
 af_inputText_content::-moz-placeholder {}
 Currently, the generated CSS will output:
 af_inputText_content_-moz-placeholder {}
 One solution would be to have a whilelist of pseudo elements that we should
 render as is rather than replace the '::' with a '_'.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent

2011-09-27 Thread Matt Cooper

I'm okay with genericDesktop.

Perhaps this isn't a concern but I wonder if there is any value in giving
any sort of time scale for this, e.g. genericDesktop2010 or
genericDesktopHtml4, etc. as I presume in 2020 it'll be (I really hope
so) nearly impossible to find an HTML display engine that doesn't display
HTML5 markup at which point HTML5 will be considered generic.

Thanks,
Matt

On Tue, Sep 27, 2011 at 12:12 PM, Pavitra Subramaniam 
pavitra.subraman...@oracle.com wrote:

 On 9/27/2011 10:37 AM, Blake Sullivan (Commented) (JIRA) wrote:

 [ https://issues.apache.org/**jira/browse/TRINIDAD-2141?**
 page=com.atlassian.jira.**plugin.system.issuetabpanels:**
 comment-tabpanel**focusedCommentId=13115738#**comment-13115738https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13115738#comment-13115738]

 Blake Sullivan commented on TRINIDAD-2141:
 --**

 This isn't a generic agent (the 'unknown' agent is actually the 'most
 generic'), it is a generic, fairly rich desktop agent.  I might go for
 genericDesktop.


 +1. I prefer the lower camelcase 'genericDesktop to genericdesktop, but
 it looks like the convention used differs

  - we already have a 'genericpda' / nokia_s60  etc


 Thanks
 Pavitra




 add a new 'browser-generic' agent
 --**

 Key: TRINIDAD-2141
 URL: https://issues.apache.org/**
 jira/browse/TRINIDAD-2141https://issues.apache.org/jira/browse/TRINIDAD-2141
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Infrastructure
Affects Versions: 1.2.15-core , 2.0.1-core
Reporter: Pavitra Subramaniam
 Attachments: JIRA2141.patch


 It would be very useful to have an agent called - 'browser-generic',
 which represents the lowest common denominator agent for all browsers.
 We also would want this to have its own capabilities that any generic
 browser agent supports today.
 This agent would be very useful in usecases where the user agent cannot
 be determined at the time of rendering.
 For example when rendering content for a page to be used as a file
 attachment in an email, this could be very useful.
 CSS rules with @agent keyword would be ignored.


 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA
 administrators: https://issues.apache.org/**jira/secure/**
 ContactAdministrators!default.**jspahttps://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
 For more information on JIRA, see: http://www.atlassian.com/**
 software/jira http://www.atlassian.com/software/jira

Re: [jira] [Commented] (TRINIDAD-2141) add a new 'browser-generic' agent

2011-09-27 Thread Matt Cooper

Works for me, thanks.

On Tue, Sep 27, 2011 at 1:05 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:

The definition is meant to be kept current. The definition is logically
the least-common-denominator of the current set of desktop browsers back to
IE7. If IE7 or some of the early versions of Safari were no longer setting
the lower bar of capability, the capabilities would increase.

-- Blake Sullivan

On 9/27/11 11:32 AM, Scott O'Bryan wrote:

-1 to timescale. In my experience, things that REQUIRE maintenance do not
work well in OS..

Scott

On 09/27/2011 12:28 PM, Matt Cooper wrote:

I'm okay with genericDesktop.

Perhaps this isn't a concern but I wonder if there is any value in giving
any sort of time scale for this, e.g. genericDesktop2010 or
genericDesktopHtml4, etc. as I presume in 2020 it'll be (I really hope
so) nearly impossible to find an HTML display engine that doesn't display
HTML5 markup at which point HTML5 will be considered generic.

Thanks,
Matt

On Tue, Sep 27, 2011 at 12:12 PM, Pavitra Subramaniam
pavitra.subraman...@oracle.com wrote:

On 9/27/2011 10:37 AM, Blake Sullivan (Commented) (JIRA) wrote:

[
https://issues.apache.org/jira/browse/TRINIDAD-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13115738#comment-13115738]

Blake Sullivan commented on TRINIDAD-2141:
--

This isn't a generic agent (the 'unknown' agent is actually the 'most
generic'), it is a generic, fairly rich desktop agent. I might go for
genericDesktop.

+1. I prefer the lower camelcase 'genericDesktop to genericdesktop,
but it looks like the convention used differs

- we already have a 'genericpda' / nokia_s60 etc

Thanks
Pavitra

add a new 'browser-generic' agent
--

Key: TRINIDAD-2141
URL:
https://issues.apache.org/jira/browse/TRINIDAD-2141
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Infrastructure
Affects Versions: 1.2.15-core , 2.0.1-core
Reporter: Pavitra Subramaniam
Attachments: JIRA2141.patch

It would be very useful to have an agent called - 'browser-generic',
which represents the lowest common denominator agent for all browsers.
We also would want this to have its own capabilities that any generic
browser agent supports today.
This agent would be very useful in usecases where the user agent cannot
be determined at the time of rendering.
For example when rendering content for a page to be used as a file
attachment in an email, this could be very useful.
CSS rules with @agent keyword would be ignored.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see:
http://www.atlassian.com/software/jira

Re: [VOTE[ Release of Trinidad Maven Plugins v. 2.0.6

2011-08-09 Thread Matt Cooper

+1

On Thu, Aug 4, 2011 at 1:45 PM, Scott O'Bryan darkar...@gmail.com wrote:

 +1


 On 08/03/2011 03:43 PM, Max Starets wrote:

 +1

 On 8/3/2011 3:54 PM, Scott O'Bryan wrote:

 Hello Everyone,

 I was running the tasks needed to get the Trinidad Maven Plugins v.
 2.0.6released and now I need a vote as to whether everything looks good or
 not.  There were some minor fixes and the plugins including adding support
 for more JSF 2.0 stuff as well as support for later versions of JDeveloper
 and Maven 3.  This tag has been in use on Trinidad Trunk for some time and
 should now be ready for a real release.

 I have generated the tag and deployed all the artifacts to the Nexus
 Repository for review.  The artifacts are as follows:

 * The generated repository artifacts [1]
 * The updated svn repository [2]

 Please take a look at the artifacts and don't forget to vote early and
 often.  :D  The vote will stay open for at least 72 hours to give people a
 chance to respond.

 Thanks,
  Scott O'Bryan

 [1] https://repository.apache.org/**content/repositories/**
 orgapachemyfaces-004https://repository.apache.org/content/repositories/orgapachemyfaces-004
 [2] https://svn.apache.org/repos/**asf/myfaces/trinidad-maven/**
 tags/maven-plugin-parent-2.0.6https://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-2.0.6

Re: [VOTE] Release of Trinidad 2.0.0

2011-04-14 Thread Matt Cooper

+1

On Thu, Apr 14, 2011 at 5:08 PM, Scott O'Bryan darkar...@gmail.com wrote:

 Hi Everyone,

 I was running the tasks needed to get the Trinidad 2.0.0 release out and
 now I need a vote as to whether everything looks good or not.  I have
 committed the recent submitted patches available for this release and it has
 undergone some considerable testing.  As per an email discussion [1], it was
 decided to take Trinidad out of beta and move it to an official release.

 Therefore, I would like to ask for a vote on this release.  All of the
 following should be ready for review:

 * The generated repository and assembly artifacts [2]
 * The generated source archive [3]
 * The updated svn repository [4]

 Please review the artifacts and vote according to the following:

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

 This vote will remain open for at least 72 hours.

 Thanks,
  Scott O'Bryan

 [1] http://old.nabble.com/-Trinidad--Release-schedule-td31297285.html
 [2]
 https://repository.apache.org/content/repositories/orgapachemyfaces-094/
 [3]
 https://repository.apache.org/content/repositories/orgapachemyfaces-094/org/apache/myfaces/trinidad/trinidad/2.0.0/trinidad-2.0.0-source-release.zip
 [4] https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0

[jira] [Updated] (TRINIDAD-2082) hidden labels don't always render in screen reader mode

2011-04-06 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-2082:
--

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
   Status: Resolved  (was: Patch Available)

 hidden labels don't always render in screen reader mode
 ---

 Key: TRINIDAD-2082
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2082
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For: 2.0.0-beta-3

 Attachments: JIRA-TRINIDAD-2082.patch, JIRA-TRINIDAD-2082v2.patch


 When in screen reader mode, we always expect hidden labels to be rendered, as 
 these hidden labels often contain information (like labels for input fields) 
 necessary for 508 and WCAG 2.0 compliance.
 The HiddenLabelUtils has a method supportsHiddenLabels() that returns false 
 if the current agent does not support hidden (off page) labels on the page. 
 When in screen reader mode, this method should always return true, as we 
 always want labels to be present in screen reader mode - regardless if they 
 correctly appear hidden or not.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (TRINIDAD-2075) The trinidad-maven maven-jdev-plugin hard-codes the context root of the jpr, should be a customizable property

2011-03-31 Thread Matt Cooper (JIRA)

The trinidad-maven maven-jdev-plugin hard-codes the context root of the jpr, 
should be a customizable property


 Key: TRINIDAD-2075
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2075
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Matt Cooper


The 
https://svn.apache.org/repos/asf/myfaces/trinidad-maven/trunk/maven-jdev-plugin/src/main/java/org/apache/myfaces/trinidadbuild/plugin/jdeveloper/JDeveloperMojo.java
 file hard-codes the web application context root to be the name of the project 
plus -context-root:

// update the webapp context root
webappContextDOM.setAttribute(v, projectName + -context-root);

This results in very long URLs and worse is not customizable; you can't just 
specify that you want demo as your context root name.

It would be nice if this could be customized by specifying a property in the 
pom.xml file of your project.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (TRINIDAD-2070) log a warning message to warn the developers if rowkey is set but not unset at the end of the request

2011-03-25 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-2070:
--

   Resolution: Fixed
Fix Version/s: 2.0.0-beta-3
 Assignee: Jeanne Waldman
   Status: Resolved  (was: Patch Available)

 log a warning message to warn the developers if rowkey is set but not unset 
 at the end of the request
 -

 Key: TRINIDAD-2070
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2070
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Yuan Gao
Assignee: Jeanne Waldman
 Fix For: 2.0.0-beta-3

 Attachments: rowkey-warning.patch


 For uixcollections, we need to set the row key to operate on a specific row, 
 after that we need to unset the row key. If we leave the row key there, it 
 could cause all sorts of issues. 
 This is to log a warning message if at the end of the request, the row key is 
 not unset. 

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Release of Trinidad 2.0.0 Beta 2 (Try 2)

2011-02-16 Thread Matt Cooper

+1

On Wed, Feb 16, 2011 at 8:20 AM, Matthias Wessendorf mat...@apache.orgwrote:

 +1

 On Wed, Feb 16, 2011 at 3:50 PM, MAX STARETS max.star...@oracle.com
 wrote:
  +1
 
  On 2/16/2011 9:48 AM, Scott O'Bryan wrote:
 
  Hey Everyone,
 
  Okay, I have checked in code to address TRINIDAD-2037 which was the issue
  raised by Matthias in the previous vote[1].  The artifacts have been
  regenerated and Matthias has tested the fix and it works.  This is still
 a
  beta release so there are still a few open bugs, but all of the unit
 tests
  pass and this beta has undergone some considerable testing since the last
  release.
 
  Therefore I would like to ask for a re-vote on this release.  All of the
  following should be ready for review:
 
  * The generated repository and assembly artifacts[2]
  * The generated source archive[3]
  * The updated svn repository[4]
 
  Please review the artifacts and vote according to the following:
 
  
  [ ] +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..
  
 
  This vote will remain open for at least 72 hours.
 
  Thanks,
Scott O'Bryan
 
  [1] http://www.mail-archive.com/dev@myfaces.apache.org/msg51466.html
  [2]
 https://repository.apache.org/content/repositories/orgapachemyfaces-015/
  [3]
 
 https://repository.apache.org/content/repositories/orgapachemyfaces-015/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-2/trinidad-2.0.0-beta-2-source-release.zip
  [4]
 
 https://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-2.0.0-beta-2
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

[jira] Created: (TRINIDAD-2033) trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents

2011-02-11 Thread Matt Cooper (JIRA)

trh:tableLayout tag doc should call out table-layout:fixed as desirable for 
programmatically-resizable cell contents


 Key: TRINIDAD-2033
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2033
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Matt Cooper
Assignee: Matt Cooper


The trh:tableLayout tag doc should call out table-layout:fixed as desirable for 
programmatically-resizable cell contents.

If you have a tableLayout and have percentage-based widths assigned to a 
cellFormat that contains a programmatically-resizable child component whose 
width is dependent on the cellFormat's percentage width, the child won't resize 
when the tableLayout resizes unless the tableLayout has an 
inlineStyle=table-layout:fixed.  This may not be obvious for people 
unfamiliar with how tables work so it needs to be mentioned in the tag 
documentation.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Resolved: (TRINIDAD-2033) trh:tableLayout tag doc should call out table-layout:fixed as desirable for programmatically-resizable cell contents

2011-02-11 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-2033.
---

Resolution: Fixed

 trh:tableLayout tag doc should call out table-layout:fixed as desirable for 
 programmatically-resizable cell contents
 

 Key: TRINIDAD-2033
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2033
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For: 1.2.15-core , 2.0.0-beta-2


 The trh:tableLayout tag doc should call out table-layout:fixed as desirable 
 for programmatically-resizable cell contents.
 If you have a tableLayout and have percentage-based widths assigned to a 
 cellFormat that contains a programmatically-resizable child component whose 
 width is dependent on the cellFormat's percentage width, the child won't 
 resize when the tableLayout resizes unless the tableLayout has an 
 inlineStyle=table-layout:fixed.  This may not be obvious for people 
 unfamiliar with how tables work so it needs to be mentioned in the tag 
 documentation.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [VOTE] Apache MyFaces Trinidad 2.0.0-beta-1

2011-01-14 Thread Matt Cooper

+1

On Fri, Jan 14, 2011 at 5:10 AM, Matthias Wessendorf mat...@apache.orgwrote:

 +1

 On Fri, Jan 14, 2011 at 1:10 PM, Matthias Wessendorf mat...@apache.org
 wrote:
  Hi,
 
  I've created a Trinidad 2.0.0-beta-1 release candidate, with the
  following artifacts
  up for a vote:
 
  SVN source tag (r1058869):
  http://svn.apache.org/repos/asf/myfaces/trinidad/tags/2.0.0-beta-1/
 
  Maven staging repo:
  https://repository.apache.org/content/repositories/orgapachemyfaces-025/
 
  Source release:
 
 https://repository.apache.org/content/repositories/orgapachemyfaces-025/org/apache/myfaces/trinidad/trinidad/2.0.0-beta-1/trinidad-2.0.0-beta-1-source-release.zip
 
  Vote will be open for 72 hours.
 
  [ ] +1  approve
  [ ] +0  no opinion
  [ ] -1  disapprove (and reason why)
 
  Thanks,
  Matthias
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: [VOTE] Apache MyFaces Trinidad 1.2.14

2011-01-14 Thread Matt Cooper

+1

On Fri, Jan 14, 2011 at 11:01 AM, Jeanne Waldman
jeanne.wald...@oracle.comwrote:

 +1

 Matthias Wessendorf wrote, On 1/10/2011 8:28 AM PT:

  Hi,

 I've created a Trinidad 1.2.14 release candidate, with the following
 artifacts
 up for a vote:

 SVN source tag (r1057250):
 http://svn.apache.org/repos/asf/myfaces/trinidad/tags/trinidad-1.2.14/

 Maven staging repo:
 https://repository.apache.org/content/repositories/orgapachemyfaces-013/

 Source release:

 https://repository.apache.org/content/repositories/orgapachemyfaces-013/org/apache/myfaces/trinidad/trinidad/1.2.14/trinidad-1.2.14-source-release.zip

 Vote will be open for 72 hours.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Thanks,
 Matthias

[jira] Commented: (TRINIDAD-1970) tr:panelPopup does not work inside tr:accordionPanel

2010-12-06 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12967250#action_12967250
 ] 

Matt Cooper commented on TRINIDAD-1970:
---

If your showDetailItem is not disclosed, this is expected because undisclosed 
content is not going to be encoded (for performance reasons).

 tr:panelPopup does not work inside tr:accordionPanel
 

 Key: TRINIDAD-1970
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1970
 Project: MyFaces Trinidad
  Issue Type: Test
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: NWDS - JSF Project with Facelets,xml
Reporter: Sayan Mandal

 In my project, I have a tr:panelPopup embedded inside a tr:panelAccordion and 
 the panelPopup(even the link for opening the popup) does not appear. But if I 
 place the panelPopup outside the panelAccordion, it works. Please comment.
 tr:panelPopup text=Click Here!
   tr:panelGroupLayout layout=vertical
 tr:goLink text=point 1 destination=http://myfaces.apache.org/
   /tr:panelGroupLayout
 /tr:panelPopup

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

[jira] Resolved: (TRINIDAD-744) Update translated message files

2010-11-30 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-744.
--

Resolution: Fixed

 Update translated message files
 ---

 Key: TRINIDAD-744
 URL: https://issues.apache.org/jira/browse/TRINIDAD-744
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Bud Osterberg
Assignee: Matthias Weßendorf
 Fix For: 1.2.14-core , 2.0.0.3-core,  1.2.15-core , 2.0.0.4-core 

 Attachments: trinidad-translations.xml, trinslations-090917.tar.gz, 
 trinslations-1.2.12.3-101004.tar.gz, trinslations-trunk-101004.tar.gz, 
 trinslations080326.zip, trinslations080326.zip.md5, 
 trinslations080326.zip.sha1, trinslations080702.zip, 
 trinslations090825.tar.gz, trinslations100414_1.2.12.3.tar.gz, 
 trinslations_090112.jar, trinslations_090421.tar.gz, trinslations_090701.jar, 
 trinslations_1.2.12.1_091009.tar.gz, trinslations_1.2.12.1_091207.tar.gz, 
 trinslations_1.2.12.2_091009.tar.gz, trinslations_1.2.12.2_091022.tar.gz, 
 trinslations_1.2.12.2_100329.zip, trinslations_1.2.12.3_100823.tar.gz, 
 trinslations_101115-1.2.12.3.tar.gz, trinslations_101130_1.2.12.3.tar.gz, 
 trinslations_trunk_100524.tar.gz, trinslations_trunk_100804.tar.gz


 Latest versions of the message files (LoggerBundle, MessageBundle, and 
 CoreBundle) need translations.

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

Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag

2010-10-04 Thread Matt Cooper

Hi Blake,

How would you recommend exposing the configuration of the viewport metadata
since it is agent-specific to iOS, Android, and Windows Mobile 7 agents?

Thanks,
Matt

On Mon, Oct 4, 2010 at 10:16 AM, Blake Sullivan
blake.sulli...@oracle.comwrote:

I'm not sure that I'm a fan of this approach. Actually, I'm not a fan at
all.

1) Our first choice should be for any agent-specific meta attributes to be
generated by the document renderer
2) Any standard attributes that happen to be rendered as meta attributes
should be exposed as document attributes
3) Support for weird meta attributes should be tag children of the document
tag and should not require the use of a tr:group.

-- Blake Sullivan

On 9/29/10 4:30 PM, Matt Cooper (JIRA) wrote:

Ability to easily create a meta tag
---

Key: TRINIDAD-1930
URL: https://issues.apache.org/jira/browse/TRINIDAD-1930
Project: MyFaces Trinidad
Issue Type: Improvement
Components: Components
Affects Versions: 1.2.14-core , 2.0.0.2-core
Reporter: Matt Cooper
Assignee: Matt Cooper

Currently it is quite tedious to create a meta tag out of a component:

tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
tr:outputText escape=false
value='lt;meta name=viewport
content=width=device-width'
id=metaTag1/
tr:outputText escape=false
value='lt;meta name=apple-mobile-web-app-capable
content=yes'
id=metaTag2/
tr:outputText escape=false
value='lt;meta http-equiv=refresh
content=2;url=./test/index.jspx'
id=metaTag3/
/tr:group
/f:facet
/tr:document

It would be much better if we had a trh:meta component that looked like
this:

tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
trh:meta name=viewport content=width=device-width/
trh:meta name=apple-mobile-web-app-capable content=yes/
trh:meta name=refresh nameType=http-equiv
content=2;url=./test/index.jspx/
/tr:group
/f:facet
/tr:document

So I would like to see a new trh:meta component that has an API like this:

Tag name:trh:meta
UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
Component type: org.apache.myfaces.trinidad.CoreMeta
The meta component generates an HTML meta tag and is intended to be used
inside either the trh:head tag or the document component's metaContainer
facet.

Events
TypePhases Description
org.apache.myfaces.trinidad.event.AttributeChangeEvent Invoke
Application, Apply Request ValuesEvent delivered to describe an
attribute change. Attribute change events are not delivered for any
programmatic change to a property. They are only delivered when a renderer
changes a property without the application's specific request. An example of
an attribute change events might include the width of a column that
supported client-side resizing.

Attributes
NameTypeSupports EL?Description
attributeChangeListener javax.el.MethodExpression Only EL
a method reference to an attribute change listener. Attribute change
events are not delivered for any programmatic change to a property. They are
only delivered when a renderer changes a property without the application's
specific request. An example of an attribute change events might include the
width of a column that supported client-side resizing.
binding org.apache.myfaces.trinidad.component.core.CoreMeta
Only EL an EL reference that will store the component instance on a
bean. This can be used to give programmatic access to a component from a
backing bean, or to move creation of the component to a backing bean.
id String No the identifier for the component. The identifier
must follow a subset of the syntax allowed in HTML:

* Must not be a zero-length String.
* First character must be an ASCII letter (A-Za-z) or an underscore
('_').
* Subsequent characters must be an ASCII letter or digit (A-Za-z0-9),
an underscore ('_'), or a dash ('-').

renderedboolean Yes whether the component is rendered.
When set to false, no output will be delivered for this component (the
component will not in any way be rendered, and cannot be made visible on the
client).
nameString Yes the name or http-equiv attribute of the meta
attribute (see nameType)
nameTypeString Yes name or http-equiv indicating which
kind of name attribute is desired (name is the most common

Re: [jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag

2010-10-04 Thread Matt Cooper

I'd like to learn more about configuring Agents in UIX, is there any good
documentation that you would recommend?  (My quick searches for information
about UIX or Trinidad Agent configuration has come up empty.)

Thanks,
Matt

On Mon, Oct 4, 2010 at 12:43 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:

  Trying again, since I got an error from the mail server.

 -- Blake

 On 10/4/10 11:25 AM, Blake Sullivan wrote:

 The document renderer should be delegating to the Agent implementation.
 This is essentially what happened in UIX, which is where the idea of the
 metacontainer facet came from (in fact as part of handling exactly this
 problem, outputting meta tags for mobile devices, in that case for Palm)

 -- Blake Sullivan



 On 10/4/10 9:41 AM, Matt Cooper wrote:

 Hi Blake,

 How would you recommend exposing the configuration of the viewport metadata
 since it is agent-specific to iOS, Android, and Windows Mobile 7 agents?

 Thanks,
 Matt

 On Mon, Oct 4, 2010 at 10:16 AM, Blake Sullivan blake.sulli...@oracle.com
  wrote:

  I'm not sure that I'm a fan of this approach.  Actually, I'm not a fan at
 all.

 1) Our first choice should be for any agent-specific meta attributes to be
 generated by the document renderer
 2) Any standard attributes that happen to be rendered as meta attributes
 should be exposed as document attributes
 3) Support for weird meta attributes should be tag children of the
 document tag and should not require the use of a tr:group.

 -- Blake Sullivan




 On 9/29/10 4:30 PM, Matt Cooper (JIRA) wrote:

 Ability to easily create a meta tag
 ---

  Key: TRINIDAD-1930
  URL:
 https://issues.apache.org/jira/browse/TRINIDAD-1930
  Project: MyFaces Trinidad
   Issue Type: Improvement
   Components: Components
 Affects Versions: 1.2.14-core ,  2.0.0.2-core
 Reporter: Matt Cooper
 Assignee: Matt Cooper


 Ability to easily create a meta tag (e.g.
 http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.htmlor
 http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new
 trh:meta tag.

 Currently it is quite tedious to create a meta tag out of a component:

 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   tr:outputText escape=false
  value='lt;meta name=viewport
 content=width=device-width'
  id=metaTag1/
   tr:outputText escape=false
  value='lt;meta name=apple-mobile-web-app-capable
 content=yes'
  id=metaTag2/
   tr:outputText escape=false
  value='lt;meta http-equiv=refresh
 content=2;url=./test/index.jspx'
  id=metaTag3/
 /tr:group
   /f:facet
 /tr:document

 It would be much better if we had a trh:meta component that looked like
 this:

 tr:document ...
   f:facet name=metaContainer
 tr:group id=metaContainer
   trh:meta name=viewport content=width=device-width/
   trh:meta name=apple-mobile-web-app-capable content=yes/
   trh:meta name=refresh nameType=http-equiv
 content=2;url=./test/index.jspx/
 /tr:group
   /f:facet
 /tr:document

 So I would like to see a new trh:meta component that has an API like
 this:

 Tag name:trh:meta
 UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
 Component type: org.apache.myfaces.trinidad.CoreMeta
 The meta component generates an HTML meta tag and is intended to be used
 inside either the trh:head tag or the document component's metaContainer
 facet.

 Events
 TypePhases  Description
 org.apache.myfaces.trinidad.event.AttributeChangeEvent  Invoke
 Application, Apply Request ValuesEvent delivered to describe an
 attribute change. Attribute change events are not delivered for any
 programmatic change to a property. They are only delivered when a renderer
 changes a property without the application's specific request. An example of
 an attribute change events might include the width of a column that
 supported client-side resizing.

 Attributes
 NameTypeSupports EL?Description
 attributeChangeListener javax.el.MethodExpression   Only EL
   a method reference to an attribute change listener. Attribute change
 events are not delivered for any programmatic change to a property. They are
 only delivered when a renderer changes a property without the application's
 specific request. An example of an attribute change events might include the
 width of a column that supported client-side resizing.
 binding org.apache.myfaces.trinidad.component.core.CoreMeta
 Only EL an EL reference that will store the component instance on a
 bean. This can be used to give programmatic access to a component from a
 backing bean, or to move creation of the component to a backing bean.
 id  String

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916634#action_12916634
]

Matt Cooper commented on TRINIDAD-1930:
---

+1; type instead of nameType works for me.

Ability to easily create a meta tag
---

Ability to easily create a meta tag (e.g.
http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safarihtmlref/articles/MetaTags.html
or http://www.webmarketingnow.com/tips/meta-tags-uncovered.html ) via a new
trh:meta tag.
Currently it is quite tedious to create a meta tag out of a component:
tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
tr:outputText escape=false
value='lt;meta name=viewport
content=width=device-width'
id=metaTag1/
tr:outputText escape=false
value='lt;meta name=apple-mobile-web-app-capable
content=yes'
id=metaTag2/
tr:outputText escape=false
value='lt;meta http-equiv=refresh
content=2;url=./test/index.jspx'
id=metaTag3/
/tr:group
/f:facet
/tr:document
It would be much better if we had a trh:meta component that looked like this:
tr:document ...
f:facet name=metaContainer
tr:group id=metaContainer
trh:meta name=viewport content=width=device-width/
trh:meta name=apple-mobile-web-app-capable content=yes/
trh:meta name=refresh nameType=http-equiv
content=2;url=./test/index.jspx/
/tr:group
/f:facet
/tr:document
So I would like to see a new trh:meta component that has an API like this:
Tag name: trh:meta
UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
Component type: org.apache.myfaces.trinidad.CoreMeta
The meta component generates an HTML meta tag and is intended to be used
inside either the trh:head tag or the document component's metaContainer
facet.
Events
Type Phases Description
org.apache.myfaces.trinidad.event.AttributeChangeEventInvoke
Application, Apply Request ValuesEvent delivered to describe an
attribute change. Attribute change events are not delivered for any
programmatic change to a property. They are only delivered when a renderer
changes a property without the application's specific request. An example of
an attribute change events might include the width of a column that supported
client-side resizing.
Attributes
Name TypeSupports EL?Description
attributeChangeListener javax.el.MethodExpression Only EL
a method reference to an attribute change listener. Attribute change events
are not delivered for any programmatic change to a property. They are only
delivered when a renderer changes a property without the application's
specific request. An example of an attribute change events might include the
width of a column that supported client-side resizing.
binding org.apache.myfaces.trinidad.component.core.CoreMeta Only EL
an EL reference that will store the component instance on a bean.
This can be used to give programmatic access to a component from a backing
bean, or to move creation of the component to a backing bean.
idString No the identifier for the component. The identifier must
follow a subset of the syntax allowed in HTML:
* Must not be a zero-length String.
* First character must be an ASCII letter (A-Za-z) or an underscore ('_').
* Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an
underscore ('_'), or a dash ('-').
rendered boolean Yes whether the component is rendered. When
set to false, no output will be delivered for this component (the component
will not in any way be rendered, and cannot be made visible on the client).
name String Yes the name or http-equiv attribute of the meta attribute
(see nameType)
nameType String Yes name or http-equiv indicating which kind of
name attribute is desired (name is the most common attribute but some older
meta tags need http-equiv)
content String Yes the content of the meta attribute

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

[jira] Commented: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12916667#action_12916667
]

Matt Cooper commented on TRINIDAD-1930:
---

Other changes for consistency with other components in the trh namespace:

UIComponent class: org.apache.myfaces.trinidad.component.html.HtmlMeta
Component type: org.apache.myfaces.trinidad.HtmlMeta

Ability to easily create a meta tag
---

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

[jira] Resolved: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-30 Thread Matt Cooper (JIRA)

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

Matt Cooper resolved TRINIDAD-1930.
---

Fix Version/s: 1.2.14-core
2.0.0.2-core
Resolution: Fixed

Ability to easily create a meta tag
---

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

[jira] Created: (TRINIDAD-1930) Ability to easily create a meta tag

2010-09-29 Thread Matt Cooper (JIRA)

Ability to easily create a meta tag
---

Currently it is quite tedious to create a meta tag out of a component:

It would be much better if we had a trh:meta component that looked like this:

So I would like to see a new trh:meta component that has an API like this:

Tag name: trh:meta
UIComponent class: org.apache.myfaces.trinidad.component.core.CoreMeta
Component type: org.apache.myfaces.trinidad.CoreMeta
The meta component generates an HTML meta tag and is intended to be used inside
either the trh:head tag or the document component's metaContainer facet.

Events
TypePhases Description
org.apache.myfaces.trinidad.event.AttributeChangeEvent Invoke Application,
Apply Request ValuesEvent delivered to describe an attribute change.
Attribute change events are not delivered for any programmatic change to a
property. They are only delivered when a renderer changes a property without
the application's specific request. An example of an attribute change events
might include the width of a column that supported client-side resizing.

Attributes
NameTypeSupports EL?Description
attributeChangeListener javax.el.MethodExpression Only EL
a method reference to an attribute change listener. Attribute change events are
not delivered for any programmatic change to a property. They are only
delivered when a renderer changes a property without the application's specific
request. An example of an attribute change events might include the width of a
column that supported client-side resizing.
binding org.apache.myfaces.trinidad.component.core.CoreMeta Only EL
an EL reference that will store the component instance on a bean. This
can be used to give programmatic access to a component from a backing bean, or
to move creation of the component to a backing bean.
id String No the identifier for the component. The identifier must
follow a subset of the syntax allowed in HTML:

* Must not be a zero-length String.
* First character must be an ASCII letter (A-Za-z) or an underscore ('_').
* Subsequent characters must be an ASCII letter or digit (A-Za-z0-9), an
underscore ('_'), or a dash ('-').

renderedboolean Yes whether the component is rendered. When
set to false, no output will be delivered for this component (the component
will not in any way be rendered, and cannot be made visible on the client).
nameString Yes the name or http-equiv attribute of the meta attribute
(see nameType)
nameTypeString Yes name or http-equiv indicating which kind of
name attribute is desired (name is the most common attribute but some older
meta tags need http-equiv)
content String Yes the content of the meta attribute

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

Re: [TRINIDAD] Skin file has Netscape, IE4 and IE5 styles in it

2010-09-21 Thread Matt Cooper

+1 -- Since Trinidad does not support IE4, IE5, nor Netscape:
http://myfaces.apache.org/trinidad/trinidad-1_2/release-notes.html
then this should be just fine.

Thanks,
Matt

On Tue, Sep 21, 2010 at 10:52 AM, Jeanne Waldman
jeanne.wald...@oracle.comwrote:

 Hi,
 While working on the enhancement to port the skinning xss files to css I
 noticed that in the base-desktop.xss file there are rules for netscape and
 IE4 and IE5.
 Can't I delete these? It will clean up the files and seems like a no
 brainer.

 Jeanne

[jira] Updated: (TRINIDAD-1913) All tr:group component attributes to specify boundary and title preferences

2010-09-14 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-1913:
--

   Status: Resolved  (was: Patch Available)
 Assignee: Matt Cooper
Fix Version/s:  2.0.0.2-core 
   Resolution: Fixed

 All tr:group component attributes to specify boundary and title preferences
 ---

 Key: TRINIDAD-1913
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1913
 Project: MyFaces Trinidad
  Issue Type: Improvement
 Environment: N/A
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For:  2.0.0.2-core 

 Attachments: TRINIDAD-1913 for Trinidad Trunk.patch

   Original Estimate: 24h
  Remaining Estimate: 24h

 When groups are rendered it is up to the container component on whether to 
 include a graphical group boundaries or title values. 
 This improvement would be to add attributes to tr:group so that a group could 
 specify it's preference to the container to either show or hide boundaries 
 and to use custom title values. Here are the new attributes:
 startBoundary
 indicates if a visual group start boundary is desired. The default value of 
 'dontCare' indicates no preference. A value of 'show' indicates a preference 
 to show a start boundary. A value of 'hide' indicates a preference to not 
 show a start boundary. Regardless of the start boundary value, whether a 
 visual boundary will be displayed is up to the group's parent component.
 endBoundary
 indicates if a visual group end boundary is desired. The default value of 
 'dontCare' indicates no preference. A value of 'show' indicates a preference 
 to show an end boundary. A value of 'hide' indicates a preference to not show 
 an end boundary. Regardless of the end boundary value, whether a visual 
 boundary will be displayed is up to the group's parent component.
 title
 a title value for the group. Whether anything is done with this title value 
 is up to the group's parent component.

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

[jira] Updated: (TRINIDAD-1877) visitTree API issues for UIXIterator (stamping components) in Trinidad 1.2.12.3 and Trunk

2010-09-01 Thread Matt Cooper (JIRA)

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

Matt Cooper updated TRINIDAD-1877:
--

Status: Resolved (was: Patch Available)
Assignee: Matt Cooper
Fix Version/s: 1.2.14-core
Resolution: Fixed

Looks like this is already in 1.2.x now also in 1.2.12.3-branch.

visitTree API issues for UIXIterator (stamping components) in Trinidad
1.2.12.3 and Trunk
--

Key: TRINIDAD-1877
URL: https://issues.apache.org/jira/browse/TRINIDAD-1877
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.12-core
Environment: All
Reporter: Kamran Kashanian
Assignee: Matt Cooper
Fix For: 1.2.14-core

Attachments: visitTree1.patch

There are different implementations of visitTree API in Trinidad Trunk and
1.2.12.x. Both implementations have problems with visiting the children of
'stamping' components (UIXIterator, UIXTable, UIXTree, etc).
For example in 1.2.12.3 branch a PPRed stamped child of a UIXIterator can
fail to render (never gets visited during encoding) because visitTree never
establishes the parent component's 'currency' before visiting the children.
In Trunk, the UIXIterator's implementation of visitTree assumes that the
direct children of UIXIterator are always non-stamped columns and skips over
visiting the direct children (goes directly to grand-children) when visiting
stamped children. This assumption is incorrect for UIXIterator (when
component is not a UIXTable/UIXTreeTable).
Attaching a proposed fix to address the issue in 1.2.12.3. The patch
overrides the visitTree API in UIXIterator and establishes the correct
'currency' before visiting the children of UIXIterator. Appreciate a review
and feedback.

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

[jira] Updated: (TRINIDAD-1893) trh:tablelayout not a layout table in screen reader mode

2010-08-26 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-1893:
--

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

 trh:tablelayout not a layout table in screen reader mode
 

 Key: TRINIDAD-1893
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1893
 Project: MyFaces Trinidad
  Issue Type: Bug
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For:  2.0.0.2-core 

 Attachments: TRINIDAD-1893 1.2.12.3-branch.patch, TRINIDAD-1893 
 trunk.patch


 trh:tableLayout should be identified as a layout table (having 
 role=presentation) when it is rendered in screen reader mode.
 TableLayoutRenderer currently calls the OutputUtils.renderDataTableAttributes 
 method to render its table, and does not get this role assignment. The 
 TableLayoutRenderer should be updated to call the 
 OutputUtils.renderLayoutTableAttributes method instead, so it will get the 
 role assignment.
 I'll create and upload a patch.

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

[jira] Updated: (TRINIDAD-1895) Issue with UIXIterator visitData implementation

2010-08-26 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-1895:
--

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

 Issue with UIXIterator visitData implementation
 ---

 Key: TRINIDAD-1895
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1895
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-alpha
Reporter: Kamran Kashanian
Assignee: Matt Cooper
 Fix For:  2.0.0.2-core 

 Attachments: visitdata.patch


 The UIXIterator 'visitData' method is called during 'visitTree' invocation to 
 visit the stamped children of UIXIterator.
 The implementation uses an IndexedRunner/KeyedRunner  to loop over all or 
 some rows and visit the contents of the row.   The issue is that the code 
 skips over direct stamped children of the UIXIterator and instead visits the 
 grandchildren.   
 Looks like the code is assuming that direct children of UIXIterator are 
 unstamped columns (UIXColumn) and should be skipped over during 
 stamping-visit.   This assumption is correct for sub-classes of UIXIterator 
 but not for UIXIterator.  UIXIterator does not have columns.
 The visiting logic is already using a NoColumnFacetsVisitContext.  So on 
 invokeVisitCallback,  it skips over any columns and visits the column 
 children.  It also handles nested columns.  
 So the proposal is to change the code in IndexedRunner/KeyedRunner as 
 follows:
 Change this:
 @Override
 protected void process(UIComponent kid, ComponentProcessingContext 
 cpContext)
 {
   if (kid.getChildCount()  0)
   {
 for (UIComponent grandKid : kid.getChildren())
 {
   if (UIXComponent.visitTree(noColumnFacetContext, grandKid, 
 visitCallback))
   {
 throw new AbortProcessingException();
   }
 }
   }
 }
 To this:
 @Override
 protected void process(UIComponent kid, ComponentProcessingContext 
 cpContext)
 {
   if (UIXComponent.visitTree(noColumnFacetContext, kid, 
 visitCallback))
   {
 throw new AbortProcessingException();
   }
 }

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

[jira] Commented: (TRINIDAD-1834) tr:showDetail prompt facet doesn't fire ActionEvents if it's closed

2010-08-13 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12898306#action_12898306
 ] 

Matt Cooper commented on TRINIDAD-1834:
---

I believe this patch will have a drastic negative impact on performance since 
with this patch, undisclosed content will be processed.

 tr:showDetail prompt facet doesn't fire ActionEvents if it's closed
 ---

 Key: TRINIDAD-1834
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1834
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: mojarra 1.2_10, facelets 1.1.14, ext-val 1.2.3
Reporter: Markus Dreher
 Attachments: patch.patch


 when I use a tr:commandLink in tr:showDetail prompt facet, the actionListener 
 is only invoke when the component is disclosed.
 tr:showDetail id=sdWeitereVornamen styleClass=showDetailInput
   f:facet name=prompt
   tr:commandLink 
 actionListener=#{einwohnerDetailsController.namensaenderung} 
 id=namensaenderungLink
 tr:image inlineStyle=width: 16px; height: 16px; 
 source= /images/bearbeiten.png /
   /tr:commandLink
   /f:facet  
 ...
 /tr:showDetail
 The actionlistener should also be invoked if it's closed. the same applies to 
 input components and validators.
 In processDecodes, (processUpdates, processValidators) in UIXShowDetail class
 , facets and children will only be processed, if the components is disclosed. 
 But facets should be processed in closed and disclosed state.

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

[jira] Commented: (TRINIDAD-1834) tr:showDetail prompt facet doesn't fire ActionEvents if it's closed

2010-08-13 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12898323#action_12898323
 ] 

Matt Cooper commented on TRINIDAD-1834:
---

If the issue is that the prompt facet is still visible and possible to click 
when the showDetail is undisclosed then perhaps the fix needs to be 
specifically for the UIXShowDetail's prompt facet--no other facets or children.

 tr:showDetail prompt facet doesn't fire ActionEvents if it's closed
 ---

 Key: TRINIDAD-1834
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1834
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.13-core 
 Environment: mojarra 1.2_10, facelets 1.1.14, ext-val 1.2.3
Reporter: Markus Dreher
 Attachments: patch.patch


 when I use a tr:commandLink in tr:showDetail prompt facet, the actionListener 
 is only invoke when the component is disclosed.
 tr:showDetail id=sdWeitereVornamen styleClass=showDetailInput
   f:facet name=prompt
   tr:commandLink 
 actionListener=#{einwohnerDetailsController.namensaenderung} 
 id=namensaenderungLink
 tr:image inlineStyle=width: 16px; height: 16px; 
 source= /images/bearbeiten.png /
   /tr:commandLink
   /f:facet  
 ...
 /tr:showDetail
 The actionlistener should also be invoked if it's closed. the same applies to 
 input components and validators.
 In processDecodes, (processUpdates, processValidators) in UIXShowDetail class
 , facets and children will only be processed, if the components is disclosed. 
 But facets should be processed in closed and disclosed state.

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

[jira] Commented: (TRINIDAD-1880) Changing the font-color of middle/top portion of a disabled tab doesn't work for Internet Explorer (v6-v8)

2010-08-12 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897806#action_12897806
]

Matt Cooper commented on TRINIDAD-1880:
---

I vaguely remember IE6 having a problem with not being able to handle a certain
kind of selector. I don't recall if it was compound selectors (e.g. .x.y),
containment selectors (e.g. .x .y), or a combination of both (e.g. .x.y
.z). It sounds like this might be what you are running into.

Can you confirm which version(s) of Internet Explorer you are having this
problem in; is this only a problem in IE6?

I don't have access to a computer that runs IE6 but a definition like this
appears to be working in IE7 and IE8.

Changing the font-color of middle/top portion of a disabled tab doesn't work
for Internet Explorer (v6-v8)
--

Key: TRINIDAD-1880
URL: https://issues.apache.org/jira/browse/TRINIDAD-1880
Project: MyFaces Trinidad
Issue Type: Bug
Components: Skinning
Affects Versions: 1.0.8-core
Environment: windows xp, ie6, ie7, ie8
trinidad package: ...-api-1.0.8.jar and ...-impl-1.0.8.jar
Reporter: teckpro

hi there,
usually the (css-) skinning for an inactive middle tab works with
af|navigationPane::tabs-inactive af|navigationPane::tabs-mid and i got no
problem there. unfortunately the documentation doesn't explain how to style
disabled-inactive tabs. so after trying a bit i found out that
af|navigationPane::tabs-inactive:disabled af|navigationPane::tabs-mid
is the correct css-class for skinning the color. but then i realized that it
has no effect at all for every version of the IE and again unfortunately our
customer works exclusively with IE and nothing else.
can someone help me or fix the problem?
thanks in advance
jonathan

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

[jira] Commented: (TRINIDAD-1880) Changing the font-color of middle/top portion of a disabled tab doesn't work for Internet Explorer (v6-v8)

2010-08-12 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897807#action_12897807
 ] 

Matt Cooper commented on TRINIDAD-1880:
---

If what you are seeing reproduces in all versions of IE then perhaps this is 
simply a matter of CSS specificity; your disabled selector is less specific 
than the selector that is winning.

Here's a good page that describes how specificity is calculated:
http://www.w3.org/TR/CSS2/cascade.html#specificity

 Changing the font-color of middle/top portion of a disabled tab doesn't work 
 for Internet Explorer (v6-v8)
 --

 Key: TRINIDAD-1880
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1880
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Affects Versions:  1.0.8-core
 Environment: windows xp, ie6, ie7, ie8
 trinidad package: ...-api-1.0.8.jar and ...-impl-1.0.8.jar
Reporter: teckpro

 hi there,
 usually the (css-) skinning for an inactive middle tab works with 
 af|navigationPane::tabs-inactive af|navigationPane::tabs-mid and i got no 
 problem there. unfortunately the documentation doesn't explain how to style 
 disabled-inactive tabs. so after trying a bit i found out that 
 af|navigationPane::tabs-inactive:disabled af|navigationPane::tabs-mid
 is the correct css-class for skinning the color. but then i realized that it 
 has no effect at all for every version of the IE and again unfortunately our 
 customer works exclusively with IE and nothing else.
 can someone help me or fix the problem?
 thanks in advance
 jonathan

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

[jira] Commented: (TRINIDAD-1870) tr:commandLink blocks tr:panelAccordion

2010-07-30 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12894074#action_12894074
 ] 

Matt Cooper commented on TRINIDAD-1870:
---

The stateSaving property in my example can be deleted, e.g. 
tr:document title=test

 tr:commandLink blocks tr:panelAccordion
 ---

 Key: TRINIDAD-1870
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1870
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
 Environment: MyFaces 2.0.1, Jetty 6.1.8, jdk 1.6.0_20, win 7
Reporter: Cedric Durmont

 I'm cleaning bugs in my app after my switch to Trinidad2, and I found
 2 problems that seems not to be on my side :
 1. I'm unable to change of tab in a panelTabbed with a click (works
 programmatically using disclosed attribute)
 2. Consider this sample.xhtml :
 ?xml version=1.0 encoding=windows-1252 ?
 !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;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:c=http://java.sun.com/jsp/jstl/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
 trh:head
titleSome title/title
tr:importScript/tr:importScript
 /trh:head
 trh:body
 tr:form
 tr:commandLink/
tr:panelAccordion
tr:showDetailItem text=foofoo/tr:showDetailItem
tr:showDetailItem text=barbar/tr:showDetailItem
 /tr:panelAccordion
 /tr:form
 /trh:body
 /html
 In this case, the panelAccordion does not work (details are not
 disclosed when you click on it). Remove the commandLink, it works
 again. Replace the commandLink by a commandButton, it works too.
 Setting attributes on the commandLink does not change the situation.

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

[jira] Commented: (TRINIDAD-1870) tr:commandLink blocks tr:panelAccordion

2010-07-30 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12894073#action_12894073
 ] 

Matt Cooper commented on TRINIDAD-1870:
---

I can confirm that in a Facelets xhtml page, this is the case.

Note that using a jspx page like this, it works fine:

?xml version=1.0 encoding=utf-8 standalone=yes ?
jsp:root xmlns:jsp=http://java.sun.com/JSP/Page; version=2.0
  xmlns:f=http://java.sun.com/jsf/core;
  xmlns:tr=http://myfaces.apache.org/trinidad;
  jsp:directive.page contentType=text/html;charset=utf-8/
  f:view
tr:document title=Apache Trinidad Demo Index stateSaving=client
   tr:form
 tr:commandLink/
 tr:panelAccordion
   tr:showDetailItem text=foofoo/tr:showDetailItem
   tr:showDetailItem text=barbar/tr:showDetailItem
 /tr:panelAccordion
  /tr:form
/tr:document
  /f:view
/jsp:root

 tr:commandLink blocks tr:panelAccordion
 ---

 Key: TRINIDAD-1870
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1870
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 2.0.0.3-core
 Environment: MyFaces 2.0.1, Jetty 6.1.8, jdk 1.6.0_20, win 7
Reporter: Cedric Durmont

 I'm cleaning bugs in my app after my switch to Trinidad2, and I found
 2 problems that seems not to be on my side :
 1. I'm unable to change of tab in a panelTabbed with a click (works
 programmatically using disclosed attribute)
 2. Consider this sample.xhtml :
 ?xml version=1.0 encoding=windows-1252 ?
 !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;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:t=http://myfaces.apache.org/tomahawk;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:c=http://java.sun.com/jsp/jstl/core;
xmlns:ui=http://java.sun.com/jsf/facelets;
 trh:head
titleSome title/title
tr:importScript/tr:importScript
 /trh:head
 trh:body
 tr:form
 tr:commandLink/
tr:panelAccordion
tr:showDetailItem text=foofoo/tr:showDetailItem
tr:showDetailItem text=barbar/tr:showDetailItem
 /tr:panelAccordion
 /tr:form
 /trh:body
 /html
 In this case, the panelAccordion does not work (details are not
 disclosed when you click on it). Remove the commandLink, it works
 again. Replace the commandLink by a commandButton, it works too.
 Setting attributes on the commandLink does not change the situation.

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

[jira] Created: (TRINIDAD-1871) Add the ability to define skinning variables so things like colors can be abstract configurations not tied to specific color uses like border-color

2010-07-30 Thread Matt Cooper (JIRA)

Add the ability to define skinning variables so things like colors can be 
abstract configurations not tied to specific color uses like border-color
---

 Key: TRINIDAD-1871
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1871
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.0.0-alpha
Reporter: Matt Cooper


A nice skinning enhancement would be to add the ability to define skinning 
variables so things like colors can be abstract configurations not tied to 
specific color uses like border-color.

For discussion purposes, let's say one of these variables is defined like this:

.AFSomeColor:variable {
  #aabbcc;
}

Notice that there is nothing forcing this color to be tied to a specific style 
property.  It is just an abstract global location for defining a given color 
value (or background image, dimension, etc.).
It is important to note that some variable may have spaces in their value.
I'm also not trying to force a syntax with this example so there may be a 
better syntax but what you see here is just one example to get the idea across.

Anyhow, once you have this variable defined, you can then use it anywhere you 
would type in a style value, e.g.:

af|table::column-resize-indicator {
  border-right: 2px dotted -tr-variable-ref(.AFSomeColor:variable);
}

then someone else could do this with the same variable:

af|someCustomComponent {
  background-color: -tr-variable-ref(.AFSomeColor:variable);
}

or even use that same color value in some future CSS property, e.g.:

af|someCustomComponent {
  -fancy-browser-custom-property: -tr-variable-ref(.AFSomeColor:variable);
}

If we abstracted our skins into some core variables, it would be super easy for 
someone to create a new skin by just changing a small number of color value 
variables.

If we really wanted to take this to a further level, we could apply transforms 
to these variables.  So for example, if someone defines a color variable in one 
location, selectors throughout the skin could consume that color variable but 
perform a transform on it, e.g. blend it a certain amount from that color to 
another color variable to create a color that is halfway between 2 colors, or 
to produce a desaturated version of that color value, etc.  If this sounds too 
much like scope creep, this can be spun off into its own JIRA issue but I 
mention it here in case it has any impact on how this skin variable idea gets 
implemented.

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

[jira] Updated: (TRINIDAD-1840) UIXTable and UIXTreeTable should provide hooks into decode/validate/updateChildrenImpl

2010-06-22 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-1840:
--

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

 UIXTable and UIXTreeTable should provide hooks into 
 decode/validate/updateChildrenImpl
 --

 Key: TRINIDAD-1840
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1840
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Components
Affects Versions: 2.0.0-alpha
 Environment: All
Reporter: Kamran Kashanian
Assignee: Matt Cooper
 Fix For: 2.0.0.3-core

 Attachments: hooks.patch


 The Trinidad UIXCollection class provides hooks for processing of 
 stamped/unstamped children and facets during decode/validate/update-model JSF 
 lifecycle phases for any collection components that extent UIXCollection. 
 See the abstract method processFacetsAndChildren in 
 decode/validate/updateChildrenImpl in UIXCollection.   This allows collection 
 component subclasses to perform special logic for handling stamped/unstamped 
 children, and facets during decode/validate/update-model phases.
 UIXTable and UIXTreeTable provide concrete implementations for 
 processFacetsAndChildren.  However,  both of these components make 
 processFacetsAndChildren final and disallow any subclasses from overriding 
 and customizing the child processing logic.
 The proposal is to make UIXTable and UIXTreeTable child component processing 
 more extensible as follows:
 1) Remove the 'final' keyword from processFacetsAndChildren and allow 
 subclasses to override these methods
 2) Provide more hooks into the existing processFacetsAndChildren processing 
 by making the utility methods in TableUtils (processStampedChildren, 
 processColumnFacets, and processFacets) public.

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

[jira] Resolved: (TRINIDAD-1839) Agent PLATFORM_IPHONE should detect iPad as well

2010-06-18 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-1839.
---

Fix Version/s: 1.2.14-core 
   1.0.13-core 
   2.0.0.3-core
   Resolution: Fixed

 Agent PLATFORM_IPHONE should detect iPad as well
 

 Key: TRINIDAD-1839
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1839
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions: 1.2.14-core , 1.0.13-core , 2.0.0.3-core
 Environment: iPad
Reporter: Dave Robinson
Assignee: Matt Cooper
 Fix For: 1.2.14-core , 1.0.13-core , 2.0.0.3-core


 We currently use agent platform iphone to identify iPhone and iPod touch. 
 It really means iOS. We should add iPad to this definition as well.

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

[jira] Created: (TRINIDAD-1830) UIXHierarchy.visitHierarchy() has a bad if statement

2010-06-11 Thread Matt Cooper (JIRA)

UIXHierarchy.visitHierarchy() has a bad if statement


 Key: TRINIDAD-1830
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1830
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper


I have found some code in UIXHierarchy.visitHierarchy() where according to the 
code's indentation, a return true should happen only if the if statement is 
true.

However, this if clause ends with a semicolon so regardless of whether the the 
clause is true, the return true will always happen.

This ends up causing UIXHierarchy.visitHierarchy() to short circuit prematurely 
(and a call to UIXTree.visitChildren() to in turn short circuit visitation of 
the view).

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

[jira] Resolved: (TRINIDAD-1830) UIXHierarchy.visitHierarchy() has a bad if statement

2010-06-11 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-1830.
---

Fix Version/s: 1.2.14-core 
2.0.0.2-core 
   Resolution: Fixed

 UIXHierarchy.visitHierarchy() has a bad if statement
 

 Key: TRINIDAD-1830
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1830
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  2.0.0.2-core 
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 I have found some code in UIXHierarchy.visitHierarchy() where according to 
 the code's indentation, a return true should happen only if the if statement 
 is true.
 However, this if clause ends with a semicolon so regardless of whether the 
 the clause is true, the return true will always happen.
 This ends up causing UIXHierarchy.visitHierarchy() to short circuit 
 prematurely (and a call to UIXTree.visitChildren() to in turn short circuit 
 visitation of the view).

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

[jira] Reopened: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2010-05-28 Thread Matt Cooper (JIRA)


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

Matt Cooper reopened TRINIDAD-885:
--


 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

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

[jira] Resolved: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2010-05-28 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-885.
--

Fix Version/s: 1.2.14-core 
   Resolution: Fixed

 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.14-core ,  2.0.0.2-core 


 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

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

Building Trinidad's trunk requires building trinidad-maven/branches/2.0.x-branch

2010-05-27 Thread Matt Cooper

Performing a mvn install on Trinidad's
https://svn.apache.org/repos/asf/myfaces/trinidad/trunk appears to require a
mvn install on trinidad-maven/branches/2.0.x-branch.

It seems that a more natural pair would be simply trinidad-maven/trunk for
Trinidad's trunk.

Is this trinidad-maven/branches/2.0.x-branch paring with trinidad/trunk
intentional?  If not then I will file a Jira ticket.

Regards,
Matt

[jira] Resolved: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2010-05-27 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-885.
--

 Assignee: Matt Cooper
Fix Version/s:  2.0.0.2-core 
   Resolution: Fixed

 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Assignee: Matt Cooper
Priority: Minor
 Fix For:  2.0.0.2-core 


 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

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

[jira] Updated: (TRINIDAD-1696) acc (screen reader mode) layout tables should include role=presentation

2010-01-29 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-1696:
--

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

 acc (screen reader mode) layout tables should include role=presentation
 -

 Key: TRINIDAD-1696
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1696
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  1.2.12-core
 Environment: all
Reporter: Dave Robinson
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.14-core 

 Attachments: TRINIDAD-1696 for trinidad 1.2.12.1.patch, TRINIDAD-1696 
 for trinidad 1.2.12.2.patch, TRINIDAD-1696 for trinidad trunk.patch

   Original Estimate: 3h
  Remaining Estimate: 3h

 When using trh:tableLayout in our page to layout some UI components, it gives
 warning during Accessibility testing:
 WARNING - This layout Table could be confused for a data table by Screen
 Readers
 From the html perspective, this warning can be fixed by setting
 role=presentation
 on the html table element.  
 We can add
 role=presentation to layout tables with the following addition to
 org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.OutputTextUtils.renderLayoutTableAttributes():
 if (CoreRenderer.isScreenReaderMode(arc))
 {
   ResponseWriter writer = context.getResponseWriter();
   writer.writeAttribute(datatable, 0, null);
 -- writer.writeAttribute(role, presentation, null);  --
 }

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

[TRINIDAD] trinidad-2.0.x branch and patches

2010-01-29 Thread Matt Cooper

Is the trinidad-2.0.x branch something permanent or do you foresee this
being rebranched from the JSF 1.2 Trinidad trunk in the future?

(I am asking because I am applying patches for TRINIDAD-1696 and would like
to know if I need an extra patch for the trinidad-2.0.x branch.)

Thanks,
Matt

Re: [TRINIDAD] trinidad-2.0.x branch and patches

2010-01-29 Thread Matt Cooper

Excellent, thank you Matthias :)

On Fri, Jan 29, 2010 at 2:39 PM, Matthias Wessendorf mat...@apache.orgwrote:

 Hey Matt,

 please do NOT apply them to 2.0.x

 every n weeks, I do merge the 1.2 fixes into the 2.0.x
 -Matthias

 On Fri, Jan 29, 2010 at 10:37 PM, Matt Cooper mcoo...@apache.org wrote:
  Is the trinidad-2.0.x branch something permanent or do you foresee this
  being rebranched from the JSF 1.2 Trinidad trunk in the future?
 
  (I am asking because I am applying patches for TRINIDAD-1696 and would
 like
  to know if I need an extra patch for the trinidad-2.0.x branch.)
 
  Thanks,
  Matt
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

[jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper (JIRA)

Skinning framework support for skin versioning
--

 Key: TRINIDAD-1691
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Reporter: Matt Cooper


UI designers periodically create new UI designs for various components with the 
goal of these designs being applied to a specific skin.  Although the visual 
design might be completely new for a given component, it is really meant to be 
available in context of other existing component designs of the same existing 
skin.

UI changes like this are sometimes considered to jarring for some customers and 
they would rather stick with the original designs.  This means that skins are 
eternally frozen after their first release so any new changes would need to be 
made in a new skin even though that new skin might be 75% identical to the 
original skin.

There is also a negative impact on customers that generate their own skin 
definitions when we introduce a new skin name.  Every skin (or skin addition) 
that they have created won't be able to uptake the new designs unless they 
physically go in and change all references from the old skin name to whatever 
the new skin's name is.  To remedy this while enabling the frozen state of 
the original designs, the skinning framework must support a concept of 
versioning.  Since the nature of software means that code lines branch into a 
vast tree structure, the version numbers of the skinning framework must fulfill 
this need.  A simple x.y will not be sufficient, we will require 
x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch 
off of the previous code branch, e.g. there will likely be a version that looks 
like 1.1.12.4.

Customers will then need a configuration option where they can specify which 
version of the skin they want to use.  (Presumably near the same location where 
they specify which skin name they want to use.)

Business needs:
Some customers need new UI designs applied to existing skins but other 
customers need the skin to remain unchanged.  Versioning will allow customers 
to optionally buy-into the new UI designs while other customers can happily 
live with the past designs.

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

Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper

Hi Blake,

Aside from the opt-in setting for end users choosing which skin to display,
application developers would also be impacted.  Application developers would
need to extend all skins instead of just extending 1 skin whose version
number could be arbitrarily changed by the end user.

Thanks,
Matt

On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:

 Matt,

 Why wouldn't it be sufficient for the new skin the extend the old?  What
 problems does this add other than forcing customers to modify their
 trinidad-config to use the new skin name in order to opt in?

 -- Blake Sullivan

 Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT:

  Skinning framework support for skin versioning
 --

 Key: TRINIDAD-1691
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Reporter: Matt Cooper


 UI designers periodically create new UI designs for various components
 with the goal of these designs being applied to a specific skin.  Although
 the visual design might be completely new for a given component, it is
 really meant to be available in context of other existing component designs
 of the same existing skin.

 UI changes like this are sometimes considered to jarring for some
 customers and they would rather stick with the original designs.  This means
 that skins are eternally frozen after their first release so any new changes
 would need to be made in a new skin even though that new skin might be 75%
 identical to the original skin.

 There is also a negative impact on customers that generate their own skin
 definitions when we introduce a new skin name.  Every skin (or skin
 addition) that they have created won't be able to uptake the new designs
 unless they physically go in and change all references from the old skin
 name to whatever the new skin's name is.  To remedy this while enabling the
 frozen state of the original designs, the skinning framework must support
 a concept of versioning.  Since the nature of software means that code lines
 branch into a vast tree structure, the version numbers of the skinning
 framework must fulfill this need.  A simple x.y will not be sufficient, we
 will require x.y.z.a.b.c.d.e.f.g and so on where each . represents
 another code branch off of the previous code branch, e.g. there will likely
 be a version that looks like 1.1.12.4.

 Customers will then need a configuration option where they can specify
 which version of the skin they want to use.  (Presumably near the same
 location where they specify which skin name they want to use.)

 Business needs:
 Some customers need new UI designs applied to existing skins but other
 customers need the skin to remain unchanged.  Versioning will allow
 customers to optionally buy-into the new UI designs while other customers
 can happily live with the past designs.

Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper

If the application developer is injecting a skin addition into skin A and
if skin B (aka version 2) extends from skin B then this is not an issue.

However, if the application developer has created their own skin that
extends skin A then the end user cannot choose skin B (aka version 2)
because the application developer is not also providing a separate skin that
extends skin B.

One of the main reasons why applications will choose extending a skin over
injecting a skin addition is that a skin addition does not guarantee any
order in which the definitions will be injected into the skin so if there
are competing definitions then it will be a matter of luck whether the
application developer's definitions will win.  However, by extending a skin,
the application developer's definitions are guaranteed to override the
existing selector of the base skins (provided the selectors are identical).

In an ideal world, we wouldn't have a skin B (version 2) at all and the
reasoning that the UI designer came up with the new design would be
justification enough for why skin A needs to change.  If there is no
justification then we should push back on the UI designer or just live with
there being a separate unrelated skin. Perhaps this isn't a very common use
case to warrant a versioning system?

Thanks,
Matt

On Wed, Jan 20, 2010 at 4:15 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:

  Do they?  I always  get confused by which is which between skin additions
 and skin extensions.  Anyway, why wouldn't skin A' that extends Skin A pick
 up all of the extensions and additions to A?  Or, is the case you are
 worried about that the customer has their own skin B that extends skin A but
 wants to pick up the changes available in A'.  However, in that case, isn't
 the change still essentially one line?  Instead of changing trinidad-config
 to point to A' (since it already points to B), the skinner changes skin B to
 extend A'?

 The reason I'm pushing back on this is that the skin files are confusing
 enough without adding skin versioning into the mix.

 -- Blake Sullivan

 Matt Cooper said the following On 1/20/2010 3:09 PM PT:

 Hi Blake,

 Aside from the opt-in setting for end users choosing which skin to display,
 application developers would also be impacted.  Application developers would
 need to extend all skins instead of just extending 1 skin whose version
 number could be arbitrarily changed by the end user.

 Thanks,
 Matt

 On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivanblake.sulli...@oracle.com 
 blake.sulli...@oracle.comwrote:



  Matt,

 Why wouldn't it be sufficient for the new skin the extend the old?  What
 problems does this add other than forcing customers to modify their
 trinidad-config to use the new skin name in order to opt in?

 -- Blake Sullivan

 Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT:

  Skinning framework support for skin versioning


  --

 Key: TRINIDAD-1691
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Reporter: Matt Cooper


 UI designers periodically create new UI designs for various components
 with the goal of these designs being applied to a specific skin.  Although
 the visual design might be completely new for a given component, it is
 really meant to be available in context of other existing component designs
 of the same existing skin.

 UI changes like this are sometimes considered to jarring for some
 customers and they would rather stick with the original designs.  This means
 that skins are eternally frozen after their first release so any new changes
 would need to be made in a new skin even though that new skin might be 75%
 identical to the original skin.

 There is also a negative impact on customers that generate their own skin
 definitions when we introduce a new skin name.  Every skin (or skin
 addition) that they have created won't be able to uptake the new designs
 unless they physically go in and change all references from the old skin
 name to whatever the new skin's name is.  To remedy this while enabling the
 frozen state of the original designs, the skinning framework must support
 a concept of versioning.  Since the nature of software means that code lines
 branch into a vast tree structure, the version numbers of the skinning
 framework must fulfill this need.  A simple x.y will not be sufficient, we
 will require x.y.z.a.b.c.d.e.f.g and so on where each . represents
 another code branch off of the previous code branch, e.g. there will likely
 be a version that looks like 1.1.12.4.

 Customers will then need a configuration option where they can specify
 which version of the skin they want to use.  (Presumably near the same
 location where they specify which skin name they want to use.)

 Business needs:
 Some customers need new UI designs

[jira] Commented: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper (JIRA)

[
https://issues.apache.org/jira/browse/TRINIDAD-1691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12803068#action_12803068
]

Matt Cooper commented on TRINIDAD-1691:
---

See a thread on this topic here:
http://markmail.org/thread/cxzae34pt45k4j4i

Skinning framework support for skin versioning
--

Key: TRINIDAD-1691
URL: https://issues.apache.org/jira/browse/TRINIDAD-1691
Project: MyFaces Trinidad
Issue Type: New Feature
Components: Skinning
Reporter: Matt Cooper

UI designers periodically create new UI designs for various components with
the goal of these designs being applied to a specific skin. Although the
visual design might be completely new for a given component, it is really
meant to be available in context of other existing component designs of the
same existing skin.
UI changes like this are sometimes considered to jarring for some customers
and they would rather stick with the original designs. This means that skins
are eternally frozen after their first release so any new changes would need
to be made in a new skin even though that new skin might be 75% identical to
the original skin.
There is also a negative impact on customers that generate their own skin
definitions when we introduce a new skin name. Every skin (or skin addition)
that they have created won't be able to uptake the new designs unless they
physically go in and change all references from the old skin name to whatever
the new skin's name is. To remedy this while enabling the frozen state of
the original designs, the skinning framework must support a concept of
versioning. Since the nature of software means that code lines branch into a
vast tree structure, the version numbers of the skinning framework must
fulfill this need. A simple x.y will not be sufficient, we will require
x.y.z.a.b.c.d.e.f.g and so on where each . represents another code branch
off of the previous code branch, e.g. there will likely be a version that
looks like 1.1.12.4.
Customers will then need a configuration option where they can specify which
version of the skin they want to use. (Presumably near the same location
where they specify which skin name they want to use.)
Business needs:
Some customers need new UI designs applied to existing skins but other
customers need the skin to remain unchanged. Versioning will allow customers
to optionally buy-into the new UI designs while other customers can happily
live with the past designs.

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

Re: [jira] Created: (TRINIDAD-1691) Skinning framework support for skin versioning

2010-01-20 Thread Matt Cooper

Thanks Blake, that works for me.

On Wed, Jan 20, 2010 at 5:41 PM, Blake Sullivan
blake.sulli...@oracle.comwrote:

  Matt,

 I don't think that an explicit versioning scheme should be necessary.  In
 your example, we have the base skin A, a version with big enough changes
 that the designer feels that it should have an new name, B, that extends A
 and an application extension of A, C.  The issue is that the user of the
 application can't choose B immediately because the C extends the original
 skin A and not the new skin B.  However, it would seem that the same logic
 that drove the original skin designer to create a new skin B rather than
 simply modifying skin A should apply in this case.  If the changes were big
 enough for us to need a new skin, doesn't this imply that other extenders of
 the original skin should need to opt in as well?  The changes that skin C
 made to change A may not be compatible with those made by skin B, so the
 application needs to verify this before making a new skin C' that extends B
 instead of A.  The grossness here would be if the application wanted to make
 both skins C and C' available and thus wanted to share overrides between the
 two.  However, the addition of inclusion support would presumably make any
 refactoring for sharing easy to take advantge of.

 -- Blake Sullivan


 Matt Cooper said the following On 1/20/2010 3:35 PM PT:

 If the application developer is injecting a skin addition into skin A and
 if skin B (aka version 2) extends from skin B then this is not an issue.

 However, if the application developer has created their own skin that
 extends skin A then the end user cannot choose skin B (aka version 2)
 because the application developer is not also providing a separate skin that
 extends skin B.

 One of the main reasons why applications will choose extending a skin over
 injecting a skin addition is that a skin addition does not guarantee any
 order in which the definitions will be injected into the skin so if there
 are competing definitions then it will be a matter of luck whether the
 application developer's definitions will win.  However, by extending a skin,
 the application developer's definitions are guaranteed to override the
 existing selector of the base skins (provided the selectors are identical).

 In an ideal world, we wouldn't have a skin B (version 2) at all and the
 reasoning that the UI designer came up with the new design would be
 justification enough for why skin A needs to change.  If there is no
 justification then we should push back on the UI designer or just live with
 there being a separate unrelated skin. Perhaps this isn't a very common use
 case to warrant a versioning system?

 Thanks,
 Matt

 On Wed, Jan 20, 2010 at 4:15 PM, Blake Sullivanblake.sulli...@oracle.com 
 blake.sulli...@oracle.comwrote:



   Do they?  I always  get confused by which is which between skin additions
 and skin extensions.  Anyway, why wouldn't skin A' that extends Skin A pick
 up all of the extensions and additions to A?  Or, is the case you are
 worried about that the customer has their own skin B that extends skin A but
 wants to pick up the changes available in A'.  However, in that case, isn't
 the change still essentially one line?  Instead of changing trinidad-config
 to point to A' (since it already points to B), the skinner changes skin B to
 extend A'?

 The reason I'm pushing back on this is that the skin files are confusing
 enough without adding skin versioning into the mix.

 -- Blake Sullivan

 Matt Cooper said the following On 1/20/2010 3:09 PM PT:

 Hi Blake,

 Aside from the opt-in setting for end users choosing which skin to display,
 application developers would also be impacted.  Application developers would
 need to extend all skins instead of just extending 1 skin whose version
 number could be arbitrarily changed by the end user.

 Thanks,
 Matt

 On Wed, Jan 20, 2010 at 3:15 PM, Blake Sullivanblake.sulli...@oracle.com 
 blake.sulli...@oracle.com blake.sulli...@oracle.com 
 blake.sulli...@oracle.comwrote:



  Matt,

 Why wouldn't it be sufficient for the new skin the extend the old?  What
 problems does this add other than forcing customers to modify their
 trinidad-config to use the new skin name in order to opt in?

 -- Blake Sullivan

 Matt Cooper (JIRA) said the following On 1/20/2010 2:09 PM PT:

  Skinning framework support for skin versioning


  --

 Key: TRINIDAD-1691
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1691

 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Skinning
Reporter: Matt Cooper


 UI designers periodically create new UI designs for various components
 with the goal of these designs being applied to a specific skin.  Although
 the visual design might be completely new for a given component, it is
 really meant to be available in context of other existing

Re: Make the new skin part of Trinidad (was: Re: [Trinidad] New Component Showcase Demo and Casablanca Skin)

2010-01-13 Thread Matt Cooper

Rather than having the casablanca skin as a separate jar file, I would
prefer to see it built-into the Trinidad jars (part of the impl project) so
consumers could use it out-of-the-box without any extra jar configuration.

Regards,
Matt

On Wed, Jan 13, 2010 at 10:02 AM, Catalin Kormos
catalin.kor...@gmail.comwrote:

 Hi Jeanne,

 Thanks for the information, the thing is the custom resource loader is
 able to locate resource files in custom location, but the main entry
 point it is still the resource servlet, which intercepts the request
 to a /adf/* and then delegates to various resource loader to actually
 locate them, right?

 I was thinking maybe there is a feature like you can have EL
 expressions in the css, to resolve the context where the resource
 servlet is mapped...

 For now we will stick with the default /adf, i think this mapping of
 the resource servlet is required by other trinidad stuff also...so
 it's like a best practice to have it declared in web.xml.

 regards,
 Catalin

 On 1/13/10, Jeanne Waldman jeanne.wald...@oracle.com wrote:
 
 
  Matthias Wessendorf wrote, On 1/12/2010 11:57 PM PT:
 
  On Tue, Jan 12, 2010 at 10:33 PM, Catalin Kormos
  catalin.kor...@gmail.com wrote:
 
 
  Hi,
  Was wondering if it would be possible to package a skin in its own jar
  file,
 
 
  yes, put the skinning xml/cfg in the JAR_FILE.jar/META-INF/
 
 
 
  so that we wouldn't need to package the skin witht the actual webapp
 that
  uses it, so that we could start having separate modules for skins?
 
 
  in theory yes.
 
 
 
  it would
  make sense for the new Casablanca skin IMHO. What do you think?
 
 
  I think we should make the new Casablance skin the default;
  the old skin we can place into a skinning module
 
  /trinidad-skins
   -/old-and-ugly-green-skin
  :-)
 
 
 
  About packaging skins, it seems possible, but I have a question:
- for example in the skin's css file, if background image urls are
  specified, for example, with a property background: white
  url(/adf/skins/casablanca/images/backgrounds/buttonLikeHeadHover.png)
  repeat-x bottom left; this will work also when the images are packaged
  in a
  jar available in the classpath, but only if the Trinidad Resource
 Servlet
  is
  mapped to /adf/*; what happens if the servlet is mapped to another url
  pattern? is there another approach, mapping independent, or are we
 stuck
  with /adf?
 
 
  I think we are stuck with the (odd) /adf
 
  Regarding its refactoring, I think it takes quite a while and maybe
  error-prone.
  Jeanne may know more on that item.
 
 
  I would stick with /adf in your path since that is the easiest.
 
  If you want to use a different mapping, say /foo, then you probably have
 to
  do this (I haven't confirmed):
  1. add a new foo.resources file to \META-INF\servlets\resources directory
- currently there is an adf.resources file and it has this one entry
  org.apache.myfaces.trinidadinternal.resource.CoreRenderKitResourceLoader
  2. add your new mapping to Trinidad's ResourceServlet to the web.xml.
   - currently there is:
servlet-mapping
  servlet-nameresources/servlet-name
  url-pattern/adf/*/url-pattern
/servlet-mapping
  3. I don't think there are dependencies on /adf in any of Trinidad's
  ResourceLoaders, but if so, then you'll need to write your own
  ResourceLoader as well.
 
 
 
 
  -Matthias
 
 
 
  regards,
  Catalin
  On Fri, Jan 8, 2010 at 12:11 PM, Catalin Kormos
  catalin.kor...@gmail.com
  wrote:
 
 
  Ok, sounds good.
 
  regards,
  Cata
 
  On 1/8/10, Matthias Wessendorf mat...@apache.org wrote:
 
 
  once the JIRA is up, I will ping gene...@incubator.a.o regarding the
  software grant
  Note: this is only discussed at the incubator committee, but no
  incubation for that piece is
  needed. Maybe (only) a software grant.
 
  -M
 
  On Fri, Jan 8, 2010 at 11:00 AM, Catalin Kormos
  catalin.kor...@gmail.com wrote:
 
 
  Hey Matthias,
 
  Great :), we'll look into the tasks you mentioned.
 
  regards,
  Catalin
 
  On 1/8/10, Matthias Wessendorf mat...@apache.org wrote:
 
 
  Hi Catalin et al,
 
  as promised, I hijacked the thread...
 
  thanks again for contributing this skin to Trinidad.
 
  The following tasks are needed:
  -A JIRA ticket that contains the patch(es)
   - for the Skin itself
   - for the GREAT demo
  = maybe a software grant is needed; If so, I will handle the
  paperwork stuff for you guys.
 
  Once the things above are sorted out, we can apply it to TRUNK.
  However, I'd like to do a RELEASE before we integrate the new
  Skin/Demo.
  I also don't mind to pretty much do a sub-release once the new
  stuff
  is in. (With maven, release are not expensive)
 
  Thanks,
  Matthias
 
  On Thu, Jan 7, 2010 at 11:37 PM, Catalin Kormos
  catalin.kor...@gmail.com wrote:
 
 
  Hello there,
  I have the pleasure to inform you about the work we did to develop
 a
  new
  skin for Trinidad and based on this a brand new, Trinidad
 components
  showcase application. You can

Re: Make the new skin part of Trinidad (was: Re: [Trinidad] New Component Showcase Demo and Casablanca Skin)

2010-01-13 Thread Matt Cooper

On Wed, Jan 13, 2010 at 10:19 AM, Matthias Wessendorf mat...@apache.orgwrote:

 On Wed, Jan 13, 2010 at 6:14 PM, Matt Cooper mcoo...@apache.org wrote:
  Rather than having the casablanca skin as a separate jar file, I would
  prefer to see it built-into the Trinidad jars (part of the impl project)
 so
  consumers could use it out-of-the-box without any extra jar
 configuration.

 I want it to become default :-)


Even better :)

Re: [Trinidad] New Component Showcase Demo and Casablanca Skin

2010-01-07 Thread Matt Cooper

Wow this looks fantastic, nice work!

Thanks,
Matt

On Thu, Jan 7, 2010 at 3:37 PM, Catalin Kormos catalin.kor...@gmail.comwrote:

 Hello there,

 I have the pleasure to inform you about the work we did to develop a new
 skin for Trinidad and based on this a brand new, Trinidad components
 showcase application. You can see it all in action at [1]. It is still a
 working in progress, in advanced state though...i mean there is always
 something to be improved; nevertheless we would like to donate the new skin
 and the new demo application to the MyFaces community, in its current state,
 and continue there if you guys agree.

 Many thanks go to my collegue Adonis who has put a lot of effort into
 designing and implementing the new skin called 'Casablanca'. I'm sure he can
 give you more details as needed about how the process went.

 A few words about the new demo:

-  first of all, many thanks to another collegue of mine, Cosmin, for
his continuos efforts with this.
- the demo is working only with facelets (there is no jsp version)
- it uses the latest 1.2.13-SNAPSHOT version of Trinidad
- we tryied to build it so it can be searched online also, currently
tryied with Google Custom Search, but this didn't work out so smoothly so
far. In any case, that's the reason for the pretty urls used. (so, no point
in trying the search currently as it doesn't work).
- in general, it replicates the examples available already for Trinidad
in the existing demo, in someplaces slightly improved.
- it tryies to provide a platform on which to build much more demos as
required as there can be always new ideas about demoing a meaningfull use
case on Trinidad, or some component behaviour.

 I'm eager to get your reactions, I think these guys did a great job so far
 and this would bring Trinidad at least a few steps closer to a more
 appealing and user friendly component set.

 regards,
 Catalin

 [1] http://example.irian.at/trinidad-showcase-casablanca

 
 Codebeat
 www.codebeat.ro

Re: [Trinidad] should event handlers be rendered for disabled components?

2009-12-10 Thread Matt Cooper

+1 to making the change and doing so in the central location

On a related note...  There's a similar attribute that input components have
called readOnly.  When this attribute is true, the component is more
interactive than when disabled is true.  If a component is not disabled but
is readOnly, those events should still be added (same as it is today).

Thanks,
Matt

On Thu, Dec 10, 2009 at 12:56 PM, Andrew Robinson 
andrew.rw.robin...@gmail.com wrote:

 While implementing the client behaviors on the Trinidad 2 branch I
 noticed something that does not sit right with me. I noticed that the
 on* attributes (onclick, onmouseover, etc.) are rendered by the
 renderEventHandlers method called from renderAllAttributes in the
 XhtmlRenderer. Nowhere do I see that the renderer is checking the
 disabled attribute, if present, to bypass the event handlers for
 disabled components except manually in the button and link renderers.

 I filed this ticket:
 https://issues.apache.org/jira/browse/TRINIDAD-1658

 I think that we should consider making a disabled check in
 renderAllAttributes and skipping the call to renderEventHandlers when
 the component is disable instead of handling this in a per-component
 renderer case.

 Opinions?

 -Andrew

[jira] Commented: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2009-12-10 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789038#action_12789038
 ] 

Matt Cooper commented on TRINIDAD-885:
--

Though, perhaps it might not be used, it looks like the new key name is is:

af|table { -tr-repeat-control-bar: true; }

According to 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SkinProperties.java

 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Priority: Minor

 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

-- 
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: (TRINIDAD-885) Provide selector to show navigation bar on bottom of table

2009-12-10 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789038#action_12789038
 ] 

Matt Cooper edited comment on TRINIDAD-885 at 12/11/09 12:07 AM:
-

Though, perhaps it might not be used, it looks like the new key name is:

af|table { -tr-repeat-control-bar: true; }

According to 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SkinProperties.java

  was (Author: mattcooper):
Though, perhaps it might not be used, it looks like the new key name is is:

af|table { -tr-repeat-control-bar: true; }

According to 
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SkinProperties.java
  
 Provide selector to show navigation bar on bottom of table 
 ---

 Key: TRINIDAD-885
 URL: https://issues.apache.org/jira/browse/TRINIDAD-885
 Project: MyFaces Trinidad
  Issue Type: Wish
Reporter: Frank Nimphius
Priority: Minor

 In ADF Faces there exist a selector -ora-repeat-control-bar that could be 
 used to show the table navigation bar on top and at the bottom of the table 
 (instead of on top only)
 af|table{ -ora-repeat-control-bar: true; } 
 A comparable selector is missing in Trinidad, which may become a problem fro 
 ADF Faces customers that migrate to Trinidad in JDeveloper 11. For a smooth 
 migration from ADF Faces to Trinidad it is highly desirable to have this 
 selector added to Trinidad

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

Re: [Vote] Trinidad 1.2.12 release

2009-08-21 Thread Matt Cooper

+1

On Fri, Aug 21, 2009 at 7:32 AM, Matthias Wessendorf mat...@apache.orgwrote:

 +1

 On Fri, Aug 21, 2009 at 3:32 PM, Matthias Wessendorfmat...@apache.org
 wrote:
  Hi,
 
  I was running the needed tasks to get the 1.2.12 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.2.12 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/trinidad1212/http://people.apache.org/%7Ematzew/trinidad1212/
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

[jira] Created: (TRINIDAD-1516) Add JSR-276 design time contract metadata for the trh:tableLayout component and its children

2009-06-22 Thread Matt Cooper (JIRA)

Add JSR-276 design time contract metadata for the trh:tableLayout component and 
its children


 Key: TRINIDAD-1516
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1516
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Priority: Minor


Add JSR-276 design time contract metadata for the trh:tableLayout component and 
its children:
https://jsf-metadata-spec-public.dev.java.net/source/browse/*checkout*/jsf-metadata-spec-public/proposals/proposed-metadata-items.html

The trh:tableLayout tag is a required ancestor for trh:rowLayout components.
The trh:rowLayout tag is a required ancestor for trh:cellFormat components.

To improve the design time experience for these components, we should add the 
metadata that will help ensure the hierarchical ancestry contracts are 
satisfied.

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

[jira] Resolved: (TRINIDAD-1516) Add JSR-276 design time contract metadata for the trh:tableLayout component and its children

2009-06-22 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-1516.
---

   Resolution: Fixed
Fix Version/s:  1.2.12-core

 Add JSR-276 design time contract metadata for the trh:tableLayout component 
 and its children
 

 Key: TRINIDAD-1516
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1516
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Build
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For:  1.2.12-core


 Add JSR-276 design time contract metadata for the trh:tableLayout component 
 and its children:
 https://jsf-metadata-spec-public.dev.java.net/source/browse/*checkout*/jsf-metadata-spec-public/proposals/proposed-metadata-items.html
 The trh:tableLayout tag is a required ancestor for trh:rowLayout components.
 The trh:rowLayout tag is a required ancestor for trh:cellFormat components.
 To improve the design time experience for these components, we should add the 
 metadata that will help ensure the hierarchical ancestry contracts are 
 satisfied.

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

[jira] Commented: (TRINIDAD-1506) ClassCastException during surefire tests when calling ExternalContextUtils.getServletContextPath()

2009-06-16 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12720166#action_12720166
 ] 

Matt Cooper commented on TRINIDAD-1506:
---

Sure, here's a sample stack trace for this issue:

java.lang.ClassCastException: 
org.apache.myfaces.trinidadinternal.renderkit.MApplication cannot be cast to 
javax.servlet.ServletContext
at 
org.apache.myfaces.trinidad.util.ExternalContextUtils.getServletContextPath(ExternalContextUtils.java:193)
at 
custom.MyRenderer._someMethodThatCallsGetServletContextPathOnExternalContextUtils(MyRenderer.java:1110)
at custom.MyRenderer.encodeAll(MyRenderer.java:69)
at 
org.apache.myfaces.trinidad.render.CoreRenderer.encodeEnd(CoreRenderer.java:335)
at 
org.apache.myfaces.trinidad.component.UIXComponentBase.encodeEnd(UIXComponentBase.java:751)
at 
org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:70)
at 
org.apache.myfaces.trinidad.render.RenderUtils.encodeRecursive(RenderUtils.java:65)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderUtils.encodeRecursive(RenderUtils.java:47)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseTest.renderRoot(RenderKitTestCase.java:213)
at 
custom.MyRenderKitTest$ClientComponentTest.runTest(MyRenderKitTest.java:282)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase$BaseTest.run(RenderKitTestCase.java:143)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at 
org.apache.myfaces.trinidadinternal.renderkit.RenderKitTestCase.run(RenderKitTestCase.java:92)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
at 
org.apache.maven.surefire.booter.SurefireBooter.run(SurefireBooter.java:198)
at 
org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.java:398)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode

[jira] Created: (TRINIDAD-1506) ClassCastException during surefire tests when calling ExternalContextUtils.getServletContextPath()

2009-06-15 Thread Matt Cooper (JIRA)

ClassCastException during surefire tests when calling 
ExternalContextUtils.getServletContextPath()
--

 Key: TRINIDAD-1506
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1506
 Project: MyFaces Trinidad
  Issue Type: Bug
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Priority: Minor


If you have a renderer that makes a call like this:

ExternalContextUtils.getServletContextPath(context.getExternalContext());

Then, when running a surefire test for a component that uses such a renderer, a 
ClassCastException will be thrown where some underlying code is expecting a 
javax.servlet.ServletContext however, a 
org.apache.myfaces.trinidadinternal.renderkit.MApplication is provided instead. 
 Perhaps MApplication needs to implement/extend ServletContext or otherwise 
ExternalContextUtils.getServletContextPath() needs to return a dummy value when 
running surefire tests.

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

[jira] Created: (TRINIDAD-1496) Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value instead of just getImageURI

2009-06-01 Thread Matt Cooper (JIRA)

Need org.apache.myfaces.trinidad.skin.Icon to expose the raw content value 
instead of just getImageURI
--

 Key: TRINIDAD-1496
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1496
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions:  1.2.11-core
Reporter: Matt Cooper
Priority: Minor


In skinning, you can define image icons in 4 different ways:

1.) Absolute URLs specify the complete URL to the resource, including the 
protocol (e.g. http://). Example:
content: url(http://incubator.apache.org/images/asf_logo_wide.gif);

2.) Relative URLs are used if the specified URL does not start with a slash 
(/) and if there's no protocol present. A relative URL is based on the skin's 
CSS file location. For instance, if the CSS is located in 
MyWebApp/skins/mySkin/ and the specified url is skinImages/myImage.gif, then 
the final URL will be /MyWebApp/skins/mySkin/skinImages/myImage.gif. Example:
content: url(skin_images/ObjectIconError.gif);

3.) Context relative URLs are resolved relatively to the context root of the 
web application. To use them, you simply have to make it start with a single 
slash (/). For instance, if the context root is /MyWebApp and the specified 
URL is /images/myImage.jpeg, the resulting URL will be 
/MyWebApp/images/myImage.jpeg. Example:
content: url(/skins/mySkin/skin_images/ObjectIconError.gif);

4.) Server relative URLs are resolved relatively to the web server as opposed 
to the context root. This allow to easily refer to resources located on another 
application on the same server. To use this type of URL, the specified URL must 
starts with two slashes (//). Example:
content: url(//MyOtherWebApp/images/myCalendar.gif);

The org.apache.myfaces.trinidad.skin.Icon class currently provides a 
getImageURI() method.  This method returns a value that has the context path 
built-in.  If a component exposes an icon attribute (there are a handful in 
Apache MyFaces Trinidad and also in another framework that has components built 
upon Trinidad), that icon String supports these same alternative mechanisms for 
referring to the icon image.  Let's say you have a component that you want to 
keep abstract but might want it to reuse existing components (e.g. a rich text 
editor with a toolbar containing buttons that you want to reuse an existing 
toolbar button component so you can have consistency in button styling).  For 
that publicly-exposed component, you will want to allow people to customize in 
skinning what the icons are for its toolbar.  These icons must be defined in 
that publicly-exposed component but then converted into a String that can be 
passed into the toolbar button component.  With the current Icon.getImageURI(), 
if a user skinned the icon image using some of the 4 above paths, either the 
icon would have 2 context paths added to it (one from the skin framework and 
one from the toolbar button resource encoding) or it would have a context path 
when it should not be including the local context path (image definition option 
#4).  For the public component's renderer to support all 4 of these image 
definition options, the org.apache.myfaces.trinidad.skin.Icon needs to expose 
some mechanism to either let it have access to the raw content value so that 
raw value can be passed along to the button or at least some kind of mechanism 
to let the public component's renderer know that it is not safe to let the 
button add its own copy of the context path (e.g. add another leading / to 
the result).

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

[Trinidad] JDK build issue

2009-03-10 Thread Matt Cooper

Hi all,

I've noticed lately that in order to build Trinidad, I have to use jdk6 on
the command line (though the settings.xml uses jdk5).

My ~/.m2/settings.xml has the following:

  profiles
profile
  idjava5.home/id
  activation
activeByDefaulttrue/activeByDefault
  /activation
  properties

jdk5.home/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/jdk5.home
  /properties
/profile
  /profiles

If I try to build using a jdk5 JAVA_HOME on the command line, I get these
test errors:

Tests in error:

initializationError0(org.apache.myfaces.trinidadinternal.renderkit.CoreRenderKitTest)

testEscapeInQuoteJS(org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtilsTest)

testDoubleEscapeInQuoteJS(org.apache.myfaces.trinidadinternal.ui.laf.base.xhtml.XhtmlLafUtilsTest)

  JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home

However, if I build using a jdk6 JAVA_HOME (and keep the jdk5 setting in the
settings.xml file), it builds fine.

  JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home

Has anyone else noticed that Trinidad requires this strange build quirk (if
so what OS are you using)?

It might be a Mac-specific issue or perhaps something else strange on my
machine.

Thank you,
Matt

Re: [Vote] Trinidad 1.2.11 release

2009-02-22 Thread Matt Cooper

+1

On Sun, Feb 22, 2009 at 7:25 AM, Gerhard Petracek
gerhard.petra...@gmail.com wrote:
 +1

 regards,
 gerhard



 2009/2/22 Matthias Wessendorf mat...@apache.org

 +1

 On Sun, Feb 22, 2009 at 2:17 PM, Matthias Wessendorf mat...@apache.org
 wrote:
  Hi,
 
  I was running the needed tasks to get the 1.2.11 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.2.11 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/core_1_2_11/
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf



 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces

Re: [Trinidad] Trinidad 1.2.x becoming trunk ...

2009-02-12 Thread Matt Cooper

+1

On Thu, Feb 12, 2009 at 11:00 AM, Matthias Wessendorf mat...@apache.org wrote:
 On Thu, Feb 12, 2009 at 6:58 PM, Gerhard Petracek
 gerhard.petra...@gmail.com wrote:
 @trunk_1.2.x - trunk:
 +1

 @andrew:
 do you mean multiple 1.0.x branches in parallel?

 -1 :-)

 just one /branches/trinidad-1.0.x

 after every release we do a TAG.
 in case there is some (security/XSS) problem
 in, let's say Trinidad 1.0.16 we just create a
 1.0.16.1 branch out of its TAG.

 -M


 regards,
 gerhard



 2009/2/12 Andrew Robinson andrew.rw.robin...@gmail.com

 +1 on both:

 trunk_1.2.x - trunk
 trunk - ../branches/1.0.##-SNAPSHOT (where ## is the latest version
 being developed)

 -Andrew

 On Thu, Feb 12, 2009 at 8:13 AM, Matthias Wessendorf mat...@apache.org
 wrote:
  Hi,
 
  we discussed this already long time ago. In the past there were no
  concerns with
  doing this move, to have Trinidad 1.2.x become TRUNK in our SVN repo.
  Next week, after a round of Trinidad CORE releases, I'd like to finally
  make the
  move happen.
 
  For Trinidad 1.0.x I am not sure if we want a *secondary* trunk
  (trunk10x) or if
  we just make it a regular branch. Having it as a branch doesn't mean
  there are
  no (maintaining) releases. Actually my plan is to have a release for
  Trinidad 1.0.x
  on a kinda 6 month interval. Or eventually earlier. Depends on the
  load of patches/bugs
  and the requests from the MyFaces community.
 
  -Matthias
 
  --
  Matthias Wessendorf
 
  blog: http://matthiaswessendorf.wordpress.com/
  sessions: http://www.slideshare.net/mwessendorf
  twitter: http://twitter.com/mwessendorf
 



 --

 http://www.irian.at

 Your JSF powerhouse -
 JSF Consulting, Development and
 Courses in English and German

 Professional Support for Apache MyFaces




 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Re: [VOTE] Release of Trinidad Plugins 1.2.9

2009-02-10 Thread Matt Cooper

+1

On Tue, Feb 10, 2009 at 10:44 AM, Gabrielle Crawford
gabrielle.crawf...@oracle.com wrote:
 +1

 Cagatay Civici wrote:

 +1
 On Feb 10, 2009, at 10:08 AM, Matthias Wessendorf wrote:

 +1

 On Tue, Feb 10, 2009 at 11:08 AM, Matthias Wessendorf mat...@apache.org
 wrote:

 Hi,

 I was running the needed tasks to get the 1.2.9 release of the Apache
 MyFaces Trinidad Maven 2 Plugins.

 The artifacts are deployed to my private Apache account ([1]).

 Please take a look at the 1.2.9 artifacts and vote.

 How to test those JARs ?

 Use the stage repo inside your pom.xml file:
 ...
 pluginRepositories
 pluginRepository
 idapache.stage/id
 nameApache Stage Repository/name
 urlhttp://people.apache.org/~matzew/plugins129//url
 layoutdefault/layout
 /pluginRepository
 /pluginRepositories
 ...

 
 [ ] +1 for community members who have reviewed and tested 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/plugins129/

 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf




 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf

Apache MyFaces Trinidad logo

2009-01-08 Thread Matt Cooper

Hi Adonis,

I can't seem to locate the non-bitmap version of the Apache MyFaces
Trinidad logo (e.g. a vector-based graphics file like PDF or
Illustrator).

Attached is the bitmap (png) version.

Thank you,
Matt
attachment: trinidad_logo.png

[jira] Created: (TRINIDAD-1350) iPod Safari not identified as iPhone as intended in documentation

2008-12-16 Thread Matt Cooper (JIRA)

iPod Safari not identified as iPhone as intended in documentation
---

 Key: TRINIDAD-1350
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1350
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Reporter: Matt Cooper
Assignee: Matt Cooper


The iPod version of Safari is not being identified as platform=iphone as is 
intended in the documentation for AgentFactoryImpl.java:
At the moment, all known iPhone and iPod touch agent strings contain iPhone 
-- not true, e.g.:
Mozila/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like 
Geckto) Version/3.0 Mobile/3A101a Safari/419.3

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

[jira] Resolved: (TRINIDAD-1350) iPod Safari not identified as iPhone as intended in documentation

2008-12-16 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-1350.
---

   Resolution: Fixed
Fix Version/s:  1.2.11-core
1.0.11-core

 iPod Safari not identified as iPhone as intended in documentation
 ---

 Key: TRINIDAD-1350
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1350
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Skinning
Reporter: Matt Cooper
Assignee: Matt Cooper
 Fix For:  1.0.11-core,  1.2.11-core


 The iPod version of Safari is not being identified as platform=iphone as is 
 intended in the documentation for AgentFactoryImpl.java:
 At the moment, all known iPhone and iPod touch agent strings contain iPhone 
 -- not true, e.g.:
 Mozila/5.0 (iPod; U; CPU like Mac OS X; en) AppleWebKit/420.1 (KHTML, like 
 Gecko) Version/3.0 Mobile/3A101a Safari/419.3

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

[jira] Created: (TRINIDAD-1297) select element is sensitive to white space and is impacted by IndentingResponseWriter

2008-11-10 Thread Matt Cooper (JIRA)

select element is sensitive to white space and is impacted by 
IndentingResponseWriter
-

 Key: TRINIDAD-1297
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1297
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.9-core, 1.0.9-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Trivial


The select element is sensitive to white space and is impacted by 
IndentingResponseWriter.  It should be added to the list of 
white-space-sensitive elements.

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

[jira] Resolved: (TRINIDAD-1297) select element is sensitive to white space and is impacted by IndentingResponseWriter

2008-11-10 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-1297.
---

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core

 select element is sensitive to white space and is impacted by 
 IndentingResponseWriter
 -

 Key: TRINIDAD-1297
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1297
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.9-core, 1.2.9-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Trivial
 Fix For: 1.2.10-core, 1.0.10-core


 The select element is sensitive to white space and is impacted by 
 IndentingResponseWriter.  It should be added to the list of 
 white-space-sensitive elements.

-- 
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 Plugins 1.2.8

2008-11-05 Thread Matt Cooper

+1

On Wed, Nov 5, 2008 at 1:01 AM, Cagatay Civici [EMAIL PROTECTED] wrote:
 +1

 On Tue, Nov 4, 2008 at 11:30 PM, Grant Smith [EMAIL PROTECTED] wrote:

 +1

 On Tue, Nov 4, 2008 at 3:02 PM, Matthias Wessendorf [EMAIL PROTECTED]
 wrote:

 +1

 On Tue, Nov 4, 2008 at 11:59 PM, Andrew Robinson
 [EMAIL PROTECTED] wrote:
  +1
  (verified new code working as intented in maven-faces-plugin  the
  binary sigs for the sha1  md5 on that jar)
 
  -Andrew
 
  On Tue, Nov 4, 2008 at 3:20 PM, Scott O'Bryan [EMAIL PROTECTED]
  wrote:
  Hi,
 
  I was running the needed tasks to get the 1.2.8 release of the Apache
  MyFaces Trinidad Maven 2 Plugins.
 
  The artifacts are deployed to my private Apache account ([1]).
 
  Please take a look at the 1.2.8 artifacts and vote.
 
  How to test those JARs ?
 
  Use the stage repo inside your pom.xml file:
  ...
  pluginRepositories
  pluginRepository
  idapache.stage/id
  nameApache Stage Repository/name
  urlhttp://people.apache.org/~sobryan/trinidad-maven/1.2.8/url
  layoutdefault/layout
  /pluginRepository
  /pluginRepositories
  ...
 
  
  [ ] +1 for community members who have reviewed and tested the bits
  [ ] +0
  [ ] -1 for fatal flaws that should cause these bits not to be
  released,
  and why..
  
 
  Thanks,
  Scott
 
  [1] http://people.apache.org/~sobryan/trinidad-maven/1.2.8
 
 
 



 --
 Matthias Wessendorf

 blog: http://matthiaswessendorf.wordpress.com/
 sessions: http://www.slideshare.net/mwessendorf
 twitter: http://twitter.com/mwessendorf



 --
 Grant Smith

[jira] Created: (TRINIDAD-1271) WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms

2008-10-17 Thread Matt Cooper (JIRA)

WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms


 Key: TRINIDAD-1271
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1271
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.9-core, 1.0.9-core,  1.2.8-core, 1.2.10-core, 
1.0.10-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor


There are WebKit implementations (e.g. Safari, Android, Google Chrome) for 
platforms like Windows and Linux but currently the Agent in Trinidad declares 
them incorrectly as using the Mac platform.  The proper platform should be 
indicated instead.

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

[jira] Resolved: (TRINIDAD-1271) WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms

2008-10-17 Thread Matt Cooper (JIRA)


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

Matt Cooper resolved TRINIDAD-1271.
---

   Resolution: Fixed
Fix Version/s: 1.0.10-core
   1.2.10-core

 WebKit Agent Uses Incorrect Platform on non-Mac and non-iPhone platforms
 

 Key: TRINIDAD-1271
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1271
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.9-core, 1.2.9-core, 1.2.10-core, 1.0.10-core
Reporter: Matt Cooper
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.10-core, 1.0.10-core


 There are WebKit implementations (e.g. Safari, Android, Google Chrome) for 
 platforms like Windows and Linux but currently the Agent in Trinidad declares 
 them incorrectly as using the Mac platform.  The proper platform should be 
 indicated instead.

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

[jira] Commented: (TRINIDAD-1267) Viewport setting is needed for Mobile Safari browsers such as iPhone, BlackBerry Bold and Storm Browsers

2008-10-16 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12640321#action_12640321
 ] 

Matt Cooper commented on TRINIDAD-1267:
---

I believe this is a dangerous change because it will cause all pages to use a 
hard-coded scale factor and prevent user scaling of the page.

Instead, for the pages that want to use such a meta tag, those pages should 
insert the meta tag into the metaContainer facet of the af:document on just 
those specific pages:
http://myfaces.apache.org/trinidad/trinidad-1_2/trinidad-api/tagdoc/tr_document.html

 Viewport setting is needed for Mobile Safari browsers such as iPhone, 
 BlackBerry Bold and Storm Browsers
 

 Key: TRINIDAD-1267
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1267
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 1.2.9-core
 Environment: Mobile Safari browsers such as iPhone, BlackBerry Bold 
 and Storm Browsers
Reporter: Tadashi Enomori
Priority: Minor
 Attachments: TRINIDAD-1267.patch


 In order to display a page in correct zoom ratio, it is necessary to add a 
 viewport meta tag in the header.

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

[jira] Created: (TRINIDAD-1238) Allow children of iterator to use partialTriggers

2008-09-22 Thread Matt Cooper (JIRA)

Allow children of iterator to use partialTriggers
-

 Key: TRINIDAD-1238
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1238
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 1.2.9-core, 1.0.9-core
Reporter: Matt Cooper


Today, if you have an iterator that stamps out components, these components 
cannot have partialTriggers where, for example, a specified button would not 
cause the component to be PPRed when clicked.

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

[jira] Commented: (TRINIDAD-1238) Allow children of iterator to use partialTriggers

2008-09-22 Thread Matt Cooper (JIRA)


[ 
https://issues.apache.org/jira/browse/TRINIDAD-1238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12633571#action_12633571
 ] 

Matt Cooper commented on TRINIDAD-1238:
---

In the test page, the desired effect is that the time stamp on the inputText 
whose id=stamped-but-not-switched would be updated when the user clicks on 
the commandButton whose id=externalButton.

 Allow children of iterator to use partialTriggers
 -

 Key: TRINIDAD-1238
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1238
 Project: MyFaces Trinidad
  Issue Type: New Feature
  Components: Components
Affects Versions: 1.0.9-core, 1.2.9-core
Reporter: Matt Cooper
 Attachments: test.jspx, testCase.diff


 Today, if you have an iterator that stamps out components, these components 
 cannot have partialTriggers where, for example, a specified button would not 
 cause the component to be PPRed when clicked.

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

[jira] Updated: (TRINIDAD-1232) Agent support for iPhone

2008-09-17 Thread Matt Cooper (JIRA)


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

Matt Cooper updated TRINIDAD-1232:
--

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

 Agent support for iPhone
 

 Key: TRINIDAD-1232
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1232
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Archetype
Affects Versions: 1.2.9-core
Reporter: Andy Schwartz
Assignee: Matt Cooper
Priority: Minor
 Fix For: 1.2.10-core, 1.0.10-core

 Attachments: TRINIDAD-1232-trunk_1.2.x.patch


 Currently the Trinidad Agent code does not distinguish between Safari running 
 on iPhone vs. Safari running on desktop.  Since there are subtle differences 
 between these two agents, the Trinidad Agent implementation should be able to 
 identify each case.

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

Re: [Trinidad] Agent support for iPhone

2008-09-17 Thread Matt Cooper

Thank you Andy,

It looks great.  I've committed your patch in trunk, trunk_1.2.x, and
1.2.9.1-branch.

Thanks,
Matt

On Wed, Sep 17, 2008 at 1:15 PM, Andy Schwartz
[EMAIL PROTECTED] wrote:
 Thanks All!

 I have logged the following issue to track this requirement:

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

 And have provided a patch.

 BTW, I decided to go with PLATFORM_IPHONE/OS_IPHONE rather than
 PLATFORM_IPHONEOS/OS_IPHONEOS.

 Andy

Re: [Trinidad] Agent support for iPhone

2008-09-16 Thread Matt Cooper

Hi Andy,

+1 to #2 -- I feel this makes the most sense.  That browser can hardly
be considered a PDA-quality browser; our interpretation of what
desktop means seems to fit more with iPhone's browser.

Thanks,
Matt

On Tue, Sep 16, 2008 at 2:24 PM, Andy Schwartz
[EMAIL PROTECTED] wrote:
 Folks -

 I would like to enhance Trinidad's Agent mechanism to
 recognize/support iPhone user agents.  We've got a couple of options
 for how to surface the iPhone agent, so wanted to run this by the
 community.

 1. Add a pda type for webkit.

 Currently, desktop Safari is identified as follows:

 Type: TYPE_DESKTOP
 Platform: PLATFORM_MACOS
 Agent: AGENT_WEBKIT

 We could distinguish between desktop and mobile safari by changing the
 agent type to pda, ie:

 Type: TYPE_PDA
 Platform: PLATFORM_MACOS
 Agent: AGENT_WEBKIT

 2. Add an iphone platform for webkit.

 Instead of mucking with the agent type, alternatively we could add a
 new platform, eg:

 Type: TYPE_DESKTOP
 Platform: PLATFORM_IPHONE_OS
 Agent: AGENT_WEBKIT

 My original thinking was to do #1.  However, in the Trinidad renderers
 there are a bunch of places where we special case content/scripts for
 the pda agent type.  As far as I can tell, none of the pda-specific
 code applies to the iPhone.  We just want our normal desktop content.
 The same goes for unsupported-agents metadata - various components are
 specified as not supported on pda, though these components should be
 supported on iPhone.

 As such, I strongly prefer #2.  This allows us to get the
 desktop-style rendering that we want, though I'll admit that it is
 somewhat awkward for iPhone to be identified as a desktop device.
 My thinking on this is that the agent type desktop would imply that
 we've got a desktop-quality browser on the device, which is the case
 for iPhone.  I also think #2 would also fit nicely with skinning - ie.
 this would allow us to use @platform to specify iPhone-specific
 styles.

 Thoughts?

 Andy

Re: [TRINIDAD]

2008-09-04 Thread Matt Cooper

There is no single component today that can provide this kind of layout.

However, I believe that you can achieve this with 2 consecutive
panelFormLayout components, e.g. something like this:

tr:panelFormLayout labelWidth=100
  tr:inputText .../
/tr:panelFormLayout
tr:panelFormLayout labelWidth=100 rows=1
  tr:inputText .../
  tr:inputText .../
/tr:panelFormLayout

Regards,
Matt

On Tue, Aug 26, 2008 at 11:38 PM, ankit mahajan
[EMAIL PROTECTED] wrote:
 sir,
 i  have a parent panelformlayout inside this i have a panelgrouplayout and i
 want to transfer properties of panelformlayout  to panelgrouplayout, is it
 possible?
 moreover i want rowspan and colspan type of things in panelformlayout. how
 can i to that..

 eg-
 i hv a parent panelformlayout inside this
 1st row has a big textbox
 2nd row contains two small txtboxes
 and both rows are properly aligned.
 how to do that.

1 2 >

1 - 100 of 199 matches

Mail list logo