Re: updating gpg KEYS file

2008-03-09 Thread Matthias Wessendorf

I'd just edit it

Sent from my iPod.

Am 08.03.2008 um 16:59 schrieb simon [EMAIL PROTECTED]:


Hi,

As I've just prepared a release for the first time, I need to add my  
gpg

signing key to the keys file at
 http://www.apache.org/dist/myfaces/KEYS

What's the correct way to do that? Do I just edit the raw file on
people.apache.org, or is there a better way?

Thanks,
Simon




[jira] Resolved: (TOBAGO-629) Wrong char-encoding on browser when using WebSphere AS

2008-03-09 Thread Bernd Bohmann (JIRA)

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

Bernd Bohmann resolved TOBAGO-629.
--

Resolution: Fixed

 Wrong char-encoding on browser when using WebSphere AS
 --

 Key: TOBAGO-629
 URL: https://issues.apache.org/jira/browse/TOBAGO-629
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Themes
Affects Versions: 1.0.15
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
 Fix For: 1.0.16, 1.1.0


 websphere 6.0? ignores the setting of the content type on the response
 Solution: Setting the content type via 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: (TOBAGO-628) Setting rendererType on TobagoMenuExtensionHandler for facelets (tx:menuRadio and tx:menuCheckbox)

2008-03-09 Thread Bernd Bohmann (JIRA)

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

Bernd Bohmann resolved TOBAGO-628.
--

Resolution: Fixed

 Setting rendererType on TobagoMenuExtensionHandler for facelets (tx:menuRadio 
 and tx:menuCheckbox)
 --

 Key: TOBAGO-628
 URL: https://issues.apache.org/jira/browse/TOBAGO-628
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Facelets
Affects Versions: 1.0.15
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
 Fix For: 1.0.16, 1.1.0




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



[jira] Created: (MYFACES-1833) UIComponentBase catches all Exceptions on broadcast

2008-03-09 Thread Thomas Spiegl (JIRA)
UIComponentBase catches all Exceptions on broadcast
---

 Key: MYFACES-1833
 URL: https://issues.apache.org/jira/browse/MYFACES-1833
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-127, JSR-252
Affects Versions:  1.1.6-SNAPSHOT, 1.2.3-SNAPSHOT
Reporter: Thomas Spiegl
Priority: Critical


In UIComponentBase.broadcast(FacesEvent event) catches all Exceptions  
rethrows a FacesException


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



[jira] Commented: (MYFACES-1833) UIComponentBase catches all Exceptions on broadcast

2008-03-09 Thread Thomas Spiegl (JIRA)

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

Thomas Spiegl commented on MYFACES-1833:


catch(Exception ex) {
throw new FacesException(Exception while calling broadcast on 
component : +getPathToComponent(this), ex);
}

the api docs say ...

Throws:
AbortProcessingException - Signal the JavaServer Faces implementation that 
no further processing on the current event should be performed 
java.lang.IllegalStateException 
java.lang.NullPointerException - if event is null


 UIComponentBase catches all Exceptions on broadcast
 ---

 Key: MYFACES-1833
 URL: https://issues.apache.org/jira/browse/MYFACES-1833
 Project: MyFaces Core
  Issue Type: Bug
  Components: JSR-127, JSR-252
Affects Versions:  1.1.6-SNAPSHOT, 1.2.3-SNAPSHOT
Reporter: Thomas Spiegl
Priority: Critical

 In UIComponentBase.broadcast(FacesEvent event) catches all Exceptions  
 rethrows a FacesException

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



[jira] Commented: (TOBAGO-572) Duplicate component id with tc:selectOneRadio

2008-03-09 Thread Bernd Bohmann (JIRA)

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

Bernd Bohmann commented on TOBAGO-572:
--

I think facelets has a bug if you are using component binding and embedded 
components.

I would suggest following change: Instead of using a binding you can set the id 
and get the component with UIComponent.findComponent.

 Duplicate component id with tc:selectOneRadio
 ---

 Key: TOBAGO-572
 URL: https://issues.apache.org/jira/browse/TOBAGO-572
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Facelets
Affects Versions: 1.0.13
 Environment: Facelets 1.1.12, MyFaces 1.1.6 snap (11.09.2007), Tobago 
 1.0.13 snap (10.12.2007)
Reporter: Guido Dubois
Assignee: Bernd Bohmann
 Attachments: tobago_faceletsexample.war


 The first time the page is rendered correctly, but if you go back you will 
 get an exception
 java.lang.IllegalStateException: Client-id : _id54 is duplicated in the faces 
 tree. Component : page:_id54, path: {Component-Path : [Class: 
 org.apache.myfaces.tobago.component.UIViewRoot,ViewId: 
 /helloWorld.xhtml][Class: org.apache.myfaces.tobago.component.UIPage,Id: 
 page][Class: org.apache.myfaces.tobago.component.UICell,Id: _id27][Class: 
 org.apache.myfaces.tobago.component.UIBox,Id: _id29][Class: 
 org.apache.myfaces.tobago.component.UICell,Id: _id54]}
 I will add a sample...

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



[jira] Commented: (TOBAGO-325) Popups background not disabled

2008-03-09 Thread Bernd Bohmann (JIRA)

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

Bernd Bohmann commented on TOBAGO-325:
--

Helmut, 
can you provide the patch for 1.1.x, please.
I will merge all changes to 1.0.16.

 Popups background not disabled
 --

 Key: TOBAGO-325
 URL: https://issues.apache.org/jira/browse/TOBAGO-325
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.0.10
 Environment: All
Reporter: Helmut Swaczinna
Assignee: Arvid Hülsebus
 Fix For: 1.0.16, 1.1.0

 Attachments: TOBAGO-325-1.diff, TOBAGO-325-2.diff, TOBAGO-325.diff


 When the page shows a popup the background page is grayed and
 you can't activate any component by mouse. But you can activate
 any component by keyboard when you use the tab key. You can execute
 actions and modifiy fields.

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



[Trinidad] Custom DialogRenderKitService

2008-03-09 Thread Thomas Möller

Hallo,

can anyone provide me with an example how to implement a
DialogRenderKitService that emulates the default behaviour hidden in
DialogServiceImpl.

I expected the implementation to be like this:

public boolean launchDialog(FacesContext context, UIViewRoot targetRoot,
UIComponent source, MapString, Object 
processParameters,
boolean useWindow, MapString, Object windowProperties)
{
RequestContext.getCurrentInstance().getDialogService().pushView(
context.getViewRoot());
context.setViewRoot(targetRoot);
context.renderResponse();

return true;
}

public boolean returnFromDialog(FacesContext context, Object returnValue)
{
RequestContext.getCurrentInstance().getDialogService().popView(true);
context.renderResponse();

return true;
}

public boolean isReturning(FacesContext context, UIComponent source)
{
// ???
}

but there are several problems:

1) The page flow scope is automatically popped from the page flow scope
stack after launchDialog has been called and this feature results in an
error popping the view in the returnFromDialog method. (I can work around
this problem if I push a dummy page flow scope on the stack at the end of
the method launchDialog but I hope this is not intended)

2) It is not obvious how to implement isReturning. I don't know how to
determine if I am returning from a dialog. The documentation explains:
Returns true if the RenderKit is aware that a dialog has returned, and the
given source component was responsible for launching that dialog. But in my
test scenario the source component was the button that closes the dialog and
this button is not identical to the button that launched the dialog!

-- 
View this message in context: 
http://www.nabble.com/-Trinidad--Custom-DialogRenderKitService-tp15933854p15933854.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.



[jira] Created: (TRINIDAD-999) tr:panelLabelAndMessage ... facet=help generates two help strings

2008-03-09 Thread Mark Dopheide (JIRA)
tr:panelLabelAndMessage ... facet=help generates two help strings
---

 Key: TRINIDAD-999
 URL: https://issues.apache.org/jira/browse/TRINIDAD-999
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.2.6-core
 Environment: facelets
Reporter: Mark Dopheide



tr:panelLabelAndMessage label=Birth Date styleClass=labelForm
showRequired=true for=dobCal
f:facet name=help
tr:outputText value=(mm/dd/yy) /
/f:facet

t:inputCalendar required=true id=dobCal renderAsPopup=true
renderPopupButtonAsImage=true value=#{signupForm.DOB} /

/tr:panelLabelAndMessage

-- The relevant part of the page gets rendered with this code 
- tr
td colspan=1 class=af_panelLabelAndMessage_help-facet
(mm/dd/yy)
/td
/tr
/tbody
/table
div class=x52
(mm/dd/yy)
  br
/div
/td
/tr

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



TRINIDAD-909 and TRINIDAD-910

2008-03-09 Thread Gerhard Petracek
hello,

before i'll commit the patch of TRINIDAD-909:
are there any suggestions concerning TRINIDAD-910?
(TRINIDAD-909 also improves the current situation of TRINIDAD-910. however,
there is still room for improvement.)

regards,
gerhard



-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


TRINIDAD-996

2008-03-09 Thread Gerhard Petracek
hello,

before i'll commit the patch of TRINIDAD-996:
are there any further suggestions?

it's an alternative mechanism (- no replacement).
(you have to activate it explicitly with a context-param.)

regards,
gerhard



-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


build plugin - an alternative annotation approach

2008-03-09 Thread simon
Hi All,

Currently, trinidad and core-1.2 use the myfaces-faces-plugin to
generate tag classes, config files and component classes.

There is some work going on to use this for core-1.1 and tomahawk too.

As I mentioned earlier, I don't like the approach used by the current
myaces-faces-plugin; I think the large number of xml config files that
are needed is not elegant or user-friendly. I proposed using some kind
of annotation in the source to drive this process instead.

I have been working on this recently, and have got the first steps
running. It's still very rough so I won't post the code, but wanted to
let you know what I'm working on. All feedback is welcome.

Here's an instrumented UIData class from core-1.1:


/**
 * Represents a component which has multiple rows of data.
 * p
 * The children of this component are expected to be 
...
 * 
 * @mfp.component 
 *   type = javax.faces.Data
 *   family = javax.faces.Data
 *   defaultRendererType = javax.faces.Table
 *   desc=tabular data
 */
public class UIData extends UIComponentBase implements NamingContainer
{
  ...
/**
 * Set the name of the temporary variable that will be exposed to
 * child components of the table to tell them what the rowData
 * object for the current row is. This value must be a literal
 * string (EL expression not permitted).
 * 
 * @mfp.property literalOnly=true
 */
public void setVar(String var)
{
_var = var;
}
}

The code I've got so far just scans the source code to build up a
meta-data structure holding the relevant data. This would then be used
to drive the file-generation step, hopefully reusing the existing code
from the myfaces-faces-plugin. In other words, I'm proposing replacing
the front end of the plugin but not the back-end.

Dumping the parsed data gives:

--dumping artifacts--
== Component
class:UIData
type:javax.faces.Data
prop:setVar
  class:java.lang.String
  isLiteral:true
  desc:Set the name of the temporary variable that will be exposed to
child components of the table to tell them what the rowData
object for the current row is. This value must be a literal
string (EL expression not permitted).
--dumped artifacts--


Note that the javadoc comments from the class are taken into the
metadata. So comments in the component, the generated tag-class and the
taglib file are automatically identical and are maintained in the
*normal* manner for java developers. 

Also, the property type is automatically inferred from the method
declaration, rather than needing to be specified in xml. By the way, the
fact that we need a method to attach the @mfp marker to does not mean
that we need an implementation; an abstract method would be fine if
code-generation is being used to then create a concrete subclass.

Possibly some of those attributes on the @mfp.component tag could be
made optional by applying standard patterns, eg looking for a public
static field with name COMPONENT_TYPE on the class.


Notes:

* The code uses the codehaus QDOX library.
* java15 annotations are not used because
  (a) we want to support 1.4
  (b) java15 compile-retention annotations are not nice to work with
  (c) we explicitly want the javadoc comments


Regards,
Simon



Re: updating gpg KEYS file

2008-03-09 Thread Bernd Bohmann
http://svn.apache.org/repos/asf/myfaces/maven/trunk/KEYS

but I see some keys are missing in svn.

Mario Ivankovits

Leonardo Uribe

Scott O'Bryan

are not available in svn.



Thomas Spiegl

is missing in http://www.apache.org/dist/myfaces/KEYS

Can you synchronize and verify the files?

I think the files in svn and www.apache.org/dist/myfaces/KEYS should be
identical.

Regards

Bernd






Matthias Wessendorf schrieb:
 I'd just edit it
 
 Sent from my iPod.
 
 Am 08.03.2008 um 16:59 schrieb simon [EMAIL PROTECTED]:
 
 Hi,

 As I've just prepared a release for the first time, I need to add my gpg
 signing key to the keys file at
  http://www.apache.org/dist/myfaces/KEYS

 What's the correct way to do that? Do I just edit the raw file on
 people.apache.org, or is there a better way?

 Thanks,
 Simon


 


Re: [orchestra] plans

2008-03-09 Thread Thomas Spiegl
On Sat, Mar 8, 2008 at 7:34 AM, Mario Ivankovits [EMAIL PROTECTED] wrote:
 Hi!
   +1 very good idea!
  
  Are those +1 due to the fact that you think that Orchestra is not the
  best place where such a component is located (which I understood), or is
  it that this component is still missunderstood ( :-( ) ?
+1 was for moving unstable code to orchestra sandbox and then release core15

  Fact is, that this component is a great timesaver when it comes to build
  master-data edit/view/list paged - typical CRUD stuff.
  Together with facelets templating and a little bit of base code creating
  new pages is just a matter of minutes and the best - these pages
  automatically follow the changes of the beans it creates (at runtime)
  the view for.

  Ciao,
  Mario





-- 
http://www.irian.at

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

Professional Support for Apache MyFaces


Re: [Trinidad] Custom DialogRenderKitService

2008-03-09 Thread Thomas Möller

After investigating another hour in this problem I am convinced that -
unfortunately - there is no solution without using nasty details of the
current trinidad implementation because the ReturnEvent is broadcasted in a
newly spawned lifecycle (see TrinidadFilterImpl) that can only be triggered
by setting a hidden request attribute
(RequestContextImpl.LAUNCH_PARAMETERS).

I would appreciate if somebody can convince me that I am wrong. 


Thomas Möller wrote:
 
 Hallo,
 
 can anyone provide me with an example how to implement a
 DialogRenderKitService that emulates the default behaviour hidden in
 DialogServiceImpl.
 
 

-- 
View this message in context: 
http://www.nabble.com/-Trinidad--Custom-DialogRenderKitService-tp15933854p15947094.html
Sent from the My Faces - Dev mailing list archive at Nabble.com.



[Tomahawk] Commit of component generation and 1.2 modules to trunk

2008-03-09 Thread Leonardo Uribe
Hi

The work for component generation for tomahawk and 1.2 modules is ready to
commit.

For component generation it follows abstract pattern and use myfaces faces
plugin.

For share 1.1 and 1.2 code it use maven-dependency plugin for unpack the
shared parts of the code.

The change on tomahawk project is very big(many week of work are here), many
files are deleted (replaced by its generated parts) and
others created (classes that implements abstract pattern).

I will commit this in 72 hours.

This change include creation of new modules like build12, core12,
sandbox/build12, sandbox/core12, so this mail is for make sure that
there is not objections about this.

The final layout of what looks like after the commit can be seen here:

http://svn.apache.org/repos/asf/myfaces/tomahawk/branches/1_1_1_2/

Suggestions are welcome

regards

Leonardo Uribe


Re: [vote] [orchestra] release Core 1.1

2008-03-09 Thread Martin Marinschek
+1,

regards,

Martin

On Sat, Mar 8, 2008 at 4:38 PM, simon [EMAIL PROTECTED] wrote:
 Hi All,

  As has been discussed recently, it is time to get a core-1.1 release out. 
 This requires releasing the orchestra parent pom too.

  The maven artifacts have been deployed to the staging repo:
  * Apache MyFaces Orchestra Maven [1]
  * Apache MyFaces Orchestra Core [2]

  The tar.gz and zip archives are deployed at [3]

  The code to be released is currently in svn under
   http://svn.apache.org/repos/asf/myfaces/orchestra/branches/
  and will be moved to the tags dir when the vote passes.

  The release notes can be found at [4]

  Please have a look at these 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..
  

  The vote will be open for 72 hours (tuesday evening european time).

  I'll start the voting with +1 (non-binding) :-)

  Regards,
  Simon

  [1] 
 http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-maven/1.1/
  [2] 
 http://people.apache.org/builds/myfaces/m2-staging-repository/org/apache/myfaces/orchestra/myfaces-orchestra-core/1.1/
  [3] http://people.apache.org/~skitching/orchestra/
  [4] 
 http://svn.apache.org/repos/asf/myfaces/orchestra/branches/core-1_1/RELEASE-NOTES.txt





-- 

http://www.irian.at

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

Professional Support for Apache MyFaces


Re: build plugin - an alternative annotation approach

2008-03-09 Thread Martin Marinschek
Sounds interesting. Will you support everything the XML-syntax allows
to supply now? E.g, long descriptions?

will it basically be an option which component-set wants to use which
frontend? Then slowly every component set could decide if it wants to
move over...

How about restoreState/saveState? the getter?

regards,

Martin

On Sun, Mar 9, 2008 at 10:20 PM, simon [EMAIL PROTECTED] wrote:
 Hi All,

  Currently, trinidad and core-1.2 use the myfaces-faces-plugin to
  generate tag classes, config files and component classes.

  There is some work going on to use this for core-1.1 and tomahawk too.

  As I mentioned earlier, I don't like the approach used by the current
  myaces-faces-plugin; I think the large number of xml config files that
  are needed is not elegant or user-friendly. I proposed using some kind
  of annotation in the source to drive this process instead.

  I have been working on this recently, and have got the first steps
  running. It's still very rough so I won't post the code, but wanted to
  let you know what I'm working on. All feedback is welcome.

  Here's an instrumented UIData class from core-1.1:


  /**
   * Represents a component which has multiple rows of data.
   * p
   * The children of this component are expected to be
  ...
   *
   * @mfp.component
   *   type = javax.faces.Data
   *   family = javax.faces.Data
   *   defaultRendererType = javax.faces.Table
   *   desc=tabular data
   */
  public class UIData extends UIComponentBase implements NamingContainer
  {
   ...
 /**
  * Set the name of the temporary variable that will be exposed to
  * child components of the table to tell them what the rowData
  * object for the current row is. This value must be a literal
  * string (EL expression not permitted).
  *
  * @mfp.property literalOnly=true
  */
 public void setVar(String var)
 {
 _var = var;
 }
  }

  The code I've got so far just scans the source code to build up a
  meta-data structure holding the relevant data. This would then be used
  to drive the file-generation step, hopefully reusing the existing code
  from the myfaces-faces-plugin. In other words, I'm proposing replacing
  the front end of the plugin but not the back-end.

  Dumping the parsed data gives:

  --dumping artifacts--
  == Component
  class:UIData
  type:javax.faces.Data
  prop:setVar
   class:java.lang.String
   isLiteral:true
   desc:Set the name of the temporary variable that will be exposed to
  child components of the table to tell them what the rowData
  object for the current row is. This value must be a literal
  string (EL expression not permitted).
  --dumped artifacts--


  Note that the javadoc comments from the class are taken into the
  metadata. So comments in the component, the generated tag-class and the
  taglib file are automatically identical and are maintained in the
  *normal* manner for java developers.

  Also, the property type is automatically inferred from the method
  declaration, rather than needing to be specified in xml. By the way, the
  fact that we need a method to attach the @mfp marker to does not mean
  that we need an implementation; an abstract method would be fine if
  code-generation is being used to then create a concrete subclass.

  Possibly some of those attributes on the @mfp.component tag could be
  made optional by applying standard patterns, eg looking for a public
  static field with name COMPONENT_TYPE on the class.


  Notes:

  * The code uses the codehaus QDOX library.
  * java15 annotations are not used because
   (a) we want to support 1.4
   (b) java15 compile-retention annotations are not nice to work with
   (c) we explicitly want the javadoc comments


  Regards,
  Simon





-- 

http://www.irian.at

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

Professional Support for Apache MyFaces