Re: [VOTE] release checkstyle module v1, release myfaces-master-pom v6

[Matthias Wessendorf]

+1 on both.

Thank you Simon.

-M

Sent from my iPod.

Am 09.07.2008 um 22:34 schrieb "Manfred Geiler" <[EMAIL PROTECTED] 
>:



+1 release checkstyle
+1 release master pom

--Manfred

On Wed, Jul 9, 2008 at 9:51 PM, simon <[EMAIL PROTECTED]> wrote:

Hi,

(1)
I'd like to make a first release of the new checkstyle module. The
release candidate has been put in a branch here:
http://svn.apache.org/repos/asf/
  myfaces/myfaces-build-tools/branches/
prepare-checkstyle-rules-1/
which will be moved to the tags dir if the vote passes.

The release artifacts can be found in the staging repo at:
http://people.apache.org/builds/myfaces/m2-staging-repository/
 org/apache/myfaces/buildtools/checkstyle-rules/1

Note that making this release does not affect any existing code; only
projects that are configured to actually use it are affected.

(2)
I'd like to make a new release of the myfaces-master-pom module. The
release candidate has been put in a branch here:
http://svn.apache.org/repos/asf/
  myfaces/myfaces-master-pom/branches/
   prepare-myfaces-6/
which will be moved to the tags dir if the vote passes.

The release artifacts can be found in the staging repo at:
http://people.apache.org/builds/myfaces/m2-staging-repository/
  org/apache/myfaces/myfaces/6/

Note that making this release does not affect any existing code; only
projects that are configured to actually use it are affected.

The previous (-5) release was based on svn revision 613141. Changes
since last release are:
* new developers bhuemer, sobryan, ctoth
* fix pmc status for imario
* tweaks to mailing list urls
* checkstyle stuff

Regards, Simon



[  ] release checkstyle
[  ] release master pom






--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

Re: [VOTE] release checkstyle module v1, release myfaces-master-pom v6

[Manfred Geiler]

+1 release checkstyle
+1 release master pom

--Manfred

On Wed, Jul 9, 2008 at 9:51 PM, simon <[EMAIL PROTECTED]> wrote:
> Hi,
>
> (1)
> I'd like to make a first release of the new checkstyle module. The
> release candidate has been put in a branch here:
>  http://svn.apache.org/repos/asf/
>myfaces/myfaces-build-tools/branches/
>  prepare-checkstyle-rules-1/
> which will be moved to the tags dir if the vote passes.
>
> The release artifacts can be found in the staging repo at:
>  http://people.apache.org/builds/myfaces/m2-staging-repository/
>   org/apache/myfaces/buildtools/checkstyle-rules/1
>
> Note that making this release does not affect any existing code; only
> projects that are configured to actually use it are affected.
>
> (2)
> I'd like to make a new release of the myfaces-master-pom module. The
> release candidate has been put in a branch here:
>  http://svn.apache.org/repos/asf/
>myfaces/myfaces-master-pom/branches/
> prepare-myfaces-6/
> which will be moved to the tags dir if the vote passes.
>
> The release artifacts can be found in the staging repo at:
>  http://people.apache.org/builds/myfaces/m2-staging-repository/
>org/apache/myfaces/myfaces/6/
>
> Note that making this release does not affect any existing code; only
> projects that are configured to actually use it are affected.
>
> The previous (-5) release was based on svn revision 613141. Changes
> since last release are:
> * new developers bhuemer, sobryan, ctoth
> * fix pmc status for imario
> * tweaks to mailing list urls
> * checkstyle stuff
>
> Regards, Simon
> 
>
>
> [  ] release checkstyle
> [  ] release master pom
>
>



-- 
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

Re: [Build] philosophy behind the myfaces build ?

[Matthias Wessendorf]

+1

It *can* be a pain in the butt to "just" run the build on subproject.

-M

Sent from my iPod.

Am 09.07.2008 um 21:35 schrieb "Manfred Geiler" <[EMAIL PROTECTED] 
>:



What matthias ment was, that we should rather have no
myfaces-inter-subproject-snapshot-dependencies.
I second that. The trunk of a MyFaces sub-project should always depend
on release versions of other projects UNLESS there is a good reason
for having a dependency to a snapshot.
What reasons are there?
1. the other project has a new feature we depend on and has not yet  
released

2. there is no release yet of the other project
3. ...more?

In all cases the snapshot dependency should be a temporary option and
as soon as the other is released we should switch to release
dependency (again).

--Manfred


On Mon, Jun 16, 2008 at 8:55 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:

Matthias Wessendorf schrieb:

Hi,

when doing a checkout of myfaces, pretty much everything is build.
Fine.
Except Trinidad and Tobago. No problem with that.

But, when just updating a single svn-folder, like tomahawk, there  
is a very
high chance that the build pretty much fails. Why? because it  
depends

on snapshots that are build via the "master myfaces" build.

In this case I am refering to the myfaces-builder plugin.

Isn't is kinda annoying that you always have to build all?
Just b/c of a snapshot dependency?
At least to me.

Why not "testing" the builder-snapshot in a branch (like
tomahawk-move-to-builder-branch).
Do a builder release, once stable. And update trunk.  (I am only  
using

builder-plug as an example).

That's what we do for Trinidad. It doesn't depend on a snapshot
plugin, so it is easy (and
straightforward) to build it.

Not sure why there is this, build the world first philosophy :-)

What do you think ?



Add the following to ~/.m2/settings.xml. Then add "-Papachesnap" when
building a project.

This allows maven to download stuff published to the snapshot
repository. Which is kind of useful when building snapshot  
projects :-)




  
apachesnap

  
apache.org
Maven Snapshots
http://people.apache.org/repo/m2-snapshot-repositoryurl>


  false


  true

  


  
apache.org
Maven Plugin Snapshots
http://people.apache.org/repo/m2-snapshot-repositoryurl>


  false


  true

  

  



Regards,
Simon






--
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

[VOTE] release checkstyle module v1, release myfaces-master-pom v6

[simon]

Hi,

(1)
I'd like to make a first release of the new checkstyle module. The
release candidate has been put in a branch here:
  http://svn.apache.org/repos/asf/
myfaces/myfaces-build-tools/branches/
  prepare-checkstyle-rules-1/
which will be moved to the tags dir if the vote passes.

The release artifacts can be found in the staging repo at:
 http://people.apache.org/builds/myfaces/m2-staging-repository/
   org/apache/myfaces/buildtools/checkstyle-rules/1

Note that making this release does not affect any existing code; only
projects that are configured to actually use it are affected.

(2)
I'd like to make a new release of the myfaces-master-pom module. The
release candidate has been put in a branch here:
  http://svn.apache.org/repos/asf/
myfaces/myfaces-master-pom/branches/
 prepare-myfaces-6/
which will be moved to the tags dir if the vote passes.

The release artifacts can be found in the staging repo at:
  http://people.apache.org/builds/myfaces/m2-staging-repository/
org/apache/myfaces/myfaces/6/

Note that making this release does not affect any existing code; only
projects that are configured to actually use it are affected.

The previous (-5) release was based on svn revision 613141. Changes
since last release are:
* new developers bhuemer, sobryan, ctoth
* fix pmc status for imario
* tweaks to mailing list urls
* checkstyle stuff

Regards, Simon



[  ] release checkstyle
[  ] release master pom

Re: [Build] philosophy behind the myfaces build ?

[Manfred Geiler]

What matthias ment was, that we should rather have no
myfaces-inter-subproject-snapshot-dependencies.
I second that. The trunk of a MyFaces sub-project should always depend
on release versions of other projects UNLESS there is a good reason
for having a dependency to a snapshot.
What reasons are there?
1. the other project has a new feature we depend on and has not yet released
2. there is no release yet of the other project
3. ...more?

In all cases the snapshot dependency should be a temporary option and
as soon as the other is released we should switch to release
dependency (again).

--Manfred


On Mon, Jun 16, 2008 at 8:55 AM, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Matthias Wessendorf schrieb:
>> Hi,
>>
>> when doing a checkout of myfaces, pretty much everything is build.
>> Fine.
>> Except Trinidad and Tobago. No problem with that.
>>
>> But, when just updating a single svn-folder, like tomahawk, there is a very
>> high chance that the build pretty much fails. Why? because it depends
>> on snapshots that are build via the "master myfaces" build.
>>
>> In this case I am refering to the myfaces-builder plugin.
>>
>> Isn't is kinda annoying that you always have to build all?
>> Just b/c of a snapshot dependency?
>> At least to me.
>>
>> Why not "testing" the builder-snapshot in a branch (like
>> tomahawk-move-to-builder-branch).
>> Do a builder release, once stable. And update trunk.  (I am only using
>> builder-plug as an example).
>>
>> That's what we do for Trinidad. It doesn't depend on a snapshot
>> plugin, so it is easy (and
>> straightforward) to build it.
>>
>> Not sure why there is this, build the world first philosophy :-)
>>
>> What do you think ?
>>
>>
> Add the following to ~/.m2/settings.xml. Then add "-Papachesnap" when
> building a project.
>
> This allows maven to download stuff published to the snapshot
> repository. Which is kind of useful when building snapshot projects :-)
>
> 
>  
>
>  apachesnap
>  
>
>  apache.org
>  Maven Snapshots
>  http://people.apache.org/repo/m2-snapshot-repository
>  
>false
>  
>  
>true
>  
>
>  
>  
>
>  apache.org
>  Maven Plugin Snapshots
>  http://people.apache.org/repo/m2-snapshot-repository
>  
>false
>  
>  
>true
>  
>
>  
>
>  
> 
>
> Regards,
> Simon
>
>



-- 
http://www.irian.at
Your JSF powerhouse - JSF Consulting,
Development and Courses in English and
German

Professional Support for Apache MyFaces

[jira] Created: (PORTLETBRIDGE-43) MyFaces action handling sometimes fails with exception from ExternalContext setRequestCharacterSetEncoding

[Michael Freedman (JIRA)]

MyFaces action handling sometimes fails with exception from ExternalContext 
setRequestCharacterSetEncoding
--

 Key: PORTLETBRIDGE-43
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-43
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0, 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


In some configurations (noteably when Facelets is used), an exception is thrown 
when MyFaces tries to set the request character encoding during an action.  The 
exception claims that the request (parameters) have already been read and hence 
one can't do this set.  This occurs because the Bridge reads the request 
parameters during ExternalContext construction to determine the view target of 
the request (if encodes this target in a render parameter).  Fix is to delay 
determining the view until Faces actually tries to determine it itself.  I.e. 
Don't resolve the view until either EC.getRequestPathInfo or 
EC.getRequestServletPath are called.  Note: because at least older version of 
the Faces RI we support don't call these (in the portlet case) but rather 
relies on a request attribute being set -- the bridge must also detect/resolve 
the view for this case 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: (PORTLETBRIDGE-42) Bridge not excluding bridge request attributes from its request scope

[Michael Freedman (JIRA)]

Bridge not excluding bridge request attributes from its request scope
-

 Key: PORTLETBRIDGE-42
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-42
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0, 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


The bridge is supposed to exclude from its managed request scope those 
attributes it creates/uses but doesn't need across a portlet request.  
Currently, these aren't being excluded.

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

[jira] Created: (PORTLETBRIDGE-41) EncodeActionURL doesn't encode valid nonFaces targets

[Michael Freedman (JIRA)]

EncodeActionURL doesn't encode valid nonFaces targets
-

 Key: PORTLETBRIDGE-41
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-41
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0, 2.0.0
Reporter: Michael Freedman


Faces allows one to construct an action URL (navigation) to a nonFaces target.  
However the bridges (ExternalContext) encodeActionURL only recognizes and 
encodes Faces targets.  What it should do when it encounters a nonFaces target 
(within the web app) is encode it distinctly from a Faces target as a portlet 
renderURL.  The bridge on receiving such a render request should recognize the 
nonFaces target and do an immediate dispatch rather then processing the request 
through Faces (lifecycle).  

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

[jira] Created: (PORTLETBRIDGE-40) Redirect during render doesn't refresh properly

[Michael Freedman (JIRA)]

Redirect during render doesn't refresh properly
---

 Key: PORTLETBRIDGE-40
 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-40
 Project: MyFaces Portlet Bridge
  Issue Type: Bug
  Components: Impl
Affects Versions: 1.0.0, 2.0.0
Reporter: Michael Freedman
Assignee: Michael Freedman


The redirect during render support doesn't retain the redirect URL across 
requests.  If a user refreshes the portlet the original (before redirect) url 
is targeted.  Though this results in the redirect replaying this doesn't always 
yield identical results than if you targeted the redirect url directly. This is 
because Faces (extensions) may encode additional state/info in the query string 
of the redirect url which changes each time such a redirect would be issued.  
To function properly the bridge must cache the redirect url, and detect that it 
should use it on subsequent refreshes (renders prior to action) instead of 
causing the redirect logic to be triggered all over again.

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

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Leonardo Uribe]

On Wed, Jul 9, 2008 at 11:38 AM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:

> I brought it up, as I thought the plan was to not promote any dojo
> based sandbox components and then make a new subproject for them.
>

Yes, that is the plan, but ask does not harm ;-) and help to identify what
is missing.


>
> On Wed, Jul 9, 2008 at 9:38 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > It uses also Dojo XML as well.
> >
> > On Wed, Jul 9, 2008 at 6:28 PM, Werner Punz <[EMAIL PROTECTED]>
> wrote:
> >>
> >> Andrew Robinson schrieb:
> >>>
> >>> Does pprPanelGroup have external dependencies - like dojo?
> >>>
> >> to my knowledge it uses the dojo.io.bind
> >> mechanisms of dojo 0.4
> >> which should be rather easy to remove.
> >>
> >>
> >> Werner
> >>
> >>
> >>
> >>> On Wed, Jul 9, 2008 at 7:52 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> 
>  Hi Leonardo,
> 
>  I will dig at the  issues in the nearest free
> time
>  slot to promote it.
>  Thanks!
> 
>  On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]>
>  wrote:
> >
> > Hi!
> >
> >> s:xmlTemplate
> >
> > Dont know much, not to say "nothing", about that.
> >
> >> s:pprPanelGroup (is this component ready? it could be good but I
> don't
> >> know if there is any objection).
> >
> > I do not think that pprPanelGroup is ready for a release, there are
> > some
> > things still missing and sometimes it stopps working.
> > Unfortunately, I have to say I am switching away from pprPanelGroup
> to
> > a4j
> > with richfaces.
> > I just have no time to look into pprPanelGroup ...
> >
> > Ciao,
> > Mario
> >
> 
> 
>  --
>  Hazem Ahmed Saleh Ahmed
>  http://www.jroller.com/page/HazemBlog
> >>>
> >>
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Andrew Robinson]

I brought it up, as I thought the plan was to not promote any dojo
based sandbox components and then make a new subproject for them.

On Wed, Jul 9, 2008 at 9:38 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> It uses also Dojo XML as well.
>
> On Wed, Jul 9, 2008 at 6:28 PM, Werner Punz <[EMAIL PROTECTED]> wrote:
>>
>> Andrew Robinson schrieb:
>>>
>>> Does pprPanelGroup have external dependencies - like dojo?
>>>
>> to my knowledge it uses the dojo.io.bind
>> mechanisms of dojo 0.4
>> which should be rather easy to remove.
>>
>>
>> Werner
>>
>>
>>
>>> On Wed, Jul 9, 2008 at 7:52 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

 Hi Leonardo,

 I will dig at the  issues in the nearest free time
 slot to promote it.
 Thanks!

 On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]>
 wrote:
>
> Hi!
>
>> s:xmlTemplate
>
> Dont know much, not to say "nothing", about that.
>
>> s:pprPanelGroup (is this component ready? it could be good but I don't
>> know if there is any objection).
>
> I do not think that pprPanelGroup is ready for a release, there are
> some
> things still missing and sometimes it stopps working.
> Unfortunately, I have to say I am switching away from pprPanelGroup to
> a4j
> with richfaces.
> I just have no time to look into pprPanelGroup ...
>
> Ciao,
> Mario
>


 --
 Hazem Ahmed Saleh Ahmed
 http://www.jroller.com/page/HazemBlog
>>>
>>
>
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Hazem Saleh]

It uses also Dojo XML as well.

On Wed, Jul 9, 2008 at 6:28 PM, Werner Punz <[EMAIL PROTECTED]> wrote:

> Andrew Robinson schrieb:
>
>> Does pprPanelGroup have external dependencies - like dojo?
>>
>>  to my knowledge it uses the dojo.io.bind
> mechanisms of dojo 0.4
> which should be rather easy to remove.
>
>
> Werner
>
>
>
>
>  On Wed, Jul 9, 2008 at 7:52 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
>>
>>> Hi Leonardo,
>>>
>>> I will dig at the  issues in the nearest free time
>>> slot to promote it.
>>> Thanks!
>>>
>>> On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]>
>>> wrote:
>>>
 Hi!

  s:xmlTemplate
>
 Dont know much, not to say "nothing", about that.

  s:pprPanelGroup (is this component ready? it could be good but I don't
> know if there is any objection).
>
 I do not think that pprPanelGroup is ready for a release, there are some
 things still missing and sometimes it stopps working.
 Unfortunately, I have to say I am switching away from pprPanelGroup to
 a4j
 with richfaces.
 I just have no time to look into pprPanelGroup ...

 Ciao,
 Mario


>>>
>>> --
>>> Hazem Ahmed Saleh Ahmed
>>> http://www.jroller.com/page/HazemBlog
>>>
>>
>>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Werner Punz]

Andrew Robinson schrieb:

Does pprPanelGroup have external dependencies - like dojo?


to my knowledge it uses the dojo.io.bind
mechanisms of dojo 0.4
which should be rather easy to remove.


Werner




On Wed, Jul 9, 2008 at 7:52 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

Hi Leonardo,

I will dig at the  issues in the nearest free time
slot to promote it.
Thanks!

On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:

Hi!


s:xmlTemplate

Dont know much, not to say "nothing", about that.


s:pprPanelGroup (is this component ready? it could be good but I don't
know if there is any objection).

I do not think that pprPanelGroup is ready for a release, there are some
things still missing and sometimes it stopps working.
Unfortunately, I have to say I am switching away from pprPanelGroup to a4j
with richfaces.
I just have no time to look into pprPanelGroup ...

Ciao,
Mario




--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Hazem Saleh]

yes Andrew it has, and I wish to remove it and add a simple Ajax engine
instead.

On Wed, Jul 9, 2008 at 6:23 PM, Andrew Robinson <
[EMAIL PROTECTED]> wrote:

> Does pprPanelGroup have external dependencies - like dojo?
>
> On Wed, Jul 9, 2008 at 7:52 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> > Hi Leonardo,
> >
> > I will dig at the  issues in the nearest free time
> > slot to promote it.
> > Thanks!
> >
> > On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]>
> wrote:
> >>
> >> Hi!
> >>
> >>> s:xmlTemplate
> >>
> >> Dont know much, not to say "nothing", about that.
> >>
> >>> s:pprPanelGroup (is this component ready? it could be good but I don't
> >>> know if there is any objection).
> >>
> >> I do not think that pprPanelGroup is ready for a release, there are some
> >> things still missing and sometimes it stopps working.
> >> Unfortunately, I have to say I am switching away from pprPanelGroup to
> a4j
> >> with richfaces.
> >> I just have no time to look into pprPanelGroup ...
> >>
> >> Ciao,
> >> Mario
> >>
> >
> >
> >
> > --
> > Hazem Ahmed Saleh Ahmed
> > http://www.jroller.com/page/HazemBlog
>



-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Andrew Robinson]

Does pprPanelGroup have external dependencies - like dojo?

On Wed, Jul 9, 2008 at 7:52 AM, Hazem Saleh <[EMAIL PROTECTED]> wrote:
> Hi Leonardo,
>
> I will dig at the  issues in the nearest free time
> slot to promote it.
> Thanks!
>
> On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
>>
>> Hi!
>>
>>> s:xmlTemplate
>>
>> Dont know much, not to say "nothing", about that.
>>
>>> s:pprPanelGroup (is this component ready? it could be good but I don't
>>> know if there is any objection).
>>
>> I do not think that pprPanelGroup is ready for a release, there are some
>> things still missing and sometimes it stopps working.
>> Unfortunately, I have to say I am switching away from pprPanelGroup to a4j
>> with richfaces.
>> I just have no time to look into pprPanelGroup ...
>>
>> Ciao,
>> Mario
>>
>
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Werner Punz]

Mario Ivankovits schrieb:

Hi!
Mario, Could you please open jira issues on the defects you found 
during your work with

.

The problems I had previously were:

1) Sometimes ppr simply stopps working, a full page refresh will happen. 
Don't know how to reproduce it. Probably you could simply ignore that 
issue.
2) You need a way how to send the component h:messages together with the 
ppr response. In a4j you could wrap any component. These component are 
then fetched with ANY ajax request.
This makes it VERY easy to have ajax submit by still being able to show 
the messages, even if a custom messagesRenderer is used (like we have 
here).
3) Support setting a new ViewRoot from within an ajax request. a4j also 
supports that. The ajax response will then be (I think aborted) and a 
full page refresh will happen. But hey, it was really cool once I 
discovered that this works at all.


More generally I have to say I find it way more harder to define all the 
client-side id's where the ppr should trigger than to simply setup a 
reRender attribute on any commandLink/commandButton.
We found it much more natural to work that way then to configure 
triggerPatterns.


a4j also provides an easy way to have a status icon somewhere on the 
page which will appear on ajax-req-start and disappear (or whatever, 
just configure the facets) on ajax-req-stop.


The main question is, what is the target of our pprPanelGroup. If it is 
to be as comfortable as the other ppr implementations I think it needs 
much more work.




The main incentive was afair to get a ppr mechanism into tomahawk, it 
started as a gsoc project, ajax4jsf was back in those days semi usable.

Have in mind since then a lot has happend Sergeij took over the a4j code
and made it working and Trinidad then merged into myfaces having its own 
mechanism, and the Trinidad people added ajax to their iframe transport 
layer.


I am not sure if it really makes sense to get our ppr promoted
(That is Ernstl Fastls job to decide, he made the component and he still 
maintains it)

maybe it makes more sense to extrapolate the Trinidad ppr or add another
existing mechanism.

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Mario Ivankovits]

Hi!
Mario, Could you please open jira issues on the defects you found 
during your work with

.

The problems I had previously were:

1) Sometimes ppr simply stopps working, a full page refresh will happen. 
Don't know how to reproduce it. Probably you could simply ignore that issue.
2) You need a way how to send the component h:messages together with the 
ppr response. In a4j you could wrap any component. These component are 
then fetched with ANY ajax request.
This makes it VERY easy to have ajax submit by still being able to show 
the messages, even if a custom messagesRenderer is used (like we have here).
3) Support setting a new ViewRoot from within an ajax request. a4j also 
supports that. The ajax response will then be (I think aborted) and a 
full page refresh will happen. But hey, it was really cool once I 
discovered that this works at all.


More generally I have to say I find it way more harder to define all the 
client-side id's where the ppr should trigger than to simply setup a 
reRender attribute on any commandLink/commandButton.
We found it much more natural to work that way then to configure 
triggerPatterns.


a4j also provides an easy way to have a status icon somewhere on the 
page which will appear on ajax-req-start and disappear (or whatever, 
just configure the facets) on ajax-req-stop.


The main question is, what is the target of our pprPanelGroup. If it is 
to be as comfortable as the other ppr implementations I think it needs 
much more work.


Ciao,
Mario


Thank you.

On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED] 
> wrote:


Hi!

s:xmlTemplate

Dont know much, not to say "nothing", about that.


s:pprPanelGroup (is this component ready? it could be good but
I don't know if there is any objection).

I do not think that pprPanelGroup is ready for a release, there
are some
things still missing and sometimes it stopps working.
Unfortunately, I have to say I am switching away from
pprPanelGroup to a4j with richfaces.
I just have no time to look into pprPanelGroup ...

Ciao,
Mario




--
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog 

Re: svn commit: r675217 - /myfaces/tomahawk/trunk/core/src/site/resources/doap_Tomahawk.rdf

[Matthias Wessendorf]

There is a doap maven plugin for this available

-M

On Wed, Jul 9, 2008 at 4:53 PM,  <[EMAIL PROTECTED]> wrote:
> Author: hazems
> Date: Wed Jul  9 07:53:44 2008
> New Revision: 675217
>
> URL: http://svn.apache.org/viewvc?rev=675217&view=rev
> Log:
> Resolving http://issues.apache.org/jira/browse/TOMAHAWK-528  Project not 
> listed in Apache's project catalog http://projects.apache.org/
>
> Added:
>myfaces/tomahawk/trunk/core/src/site/resources/doap_Tomahawk.rdf
>
> Added: myfaces/tomahawk/trunk/core/src/site/resources/doap_Tomahawk.rdf
> URL: 
> http://svn.apache.org/viewvc/myfaces/tomahawk/trunk/core/src/site/resources/doap_Tomahawk.rdf?rev=675217&view=auto
> ==
> --- myfaces/tomahawk/trunk/core/src/site/resources/doap_Tomahawk.rdf (added)
> +++ myfaces/tomahawk/trunk/core/src/site/resources/doap_Tomahawk.rdf Wed Jul  
> 9 07:53:44 2008
> @@ -0,0 +1,62 @@
> +
> +
> + + xmlns="http://usefulinc.com/ns/doap#";
> + xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";
> + xmlns:asfext="http://projects.apache.org/ns/asfext#";
> + xmlns:foaf="http://xmlns.com/foaf/0.1/";>
> +
> +  http://MyFaces.rdf.apache.org/";>
> +2006-02-28
> +http://usefulinc.com/doap/licenses/asl20"; />
> +Apache Tomahawk
> +http://myfaces.apache.org"; />
> +http://myfaces.apache.org"; />
> +Tomahawk provides a series of JSF components that go beyond 
> the JSF specification.
> +Tomahawk provides a series of JSF components that go beyond 
> the JSF specification. These components are 100% compatible with the Sun JSF 
> 1.1 Reference Implementation (RI) or any other JSF 1.1 compatible 
> implementation. Of course the custom components can also be used with the 
> Apache MyFaces JSF implementation.
> + rdf:resource="http://issues.apache.org/jira/browse/TOMAHAWK"; />
> +http://myfaces.apache.org/mail-lists.html"; />
> +http://myfaces.apache.org/download.html"; />
> +Java
> + rdf:resource="http://projects.apache.org/category/web-framework"; />
> +
> +  
> +Latest stable release
> +2006-06-14
> +1.1.3
> +  
> +  
> +Apache Tomahawk 1.1.2
> +2006-05-09
> +1.1.2
> +  
> +
> +
> +  
> + rdf:resource="http://svn.apache.org/repos/asf/myfaces/current"/>
> + rdf:resource="http://svn.apache.org/viewcvs.cgi/myfaces/current"/>
> +  
> +
> +
> +  
> +Manfred Geiler
> +  mailto:[EMAIL PROTECTED]"/>
> +  
> +
> +
> +  
> +  JavaServer Faces
> +  JCP
> +  JSR 127
> +   rdf:resource="http://www.jcp.org/en/jsr/detail?id=127"/>
> +  
> +
> +  
> +
>
>
>



-- 
Matthias Wessendorf

further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org

[jira] Resolved: (TOMAHAWK-528) Project not listed in Apache's project catalog http://projects.apache.org/

[Hazem Saleh (JIRA)]

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

Hazem Saleh resolved TOMAHAWK-528.
--

   Resolution: Fixed
Fix Version/s: 1.1.7-SNAPSHOT

> Project not listed in Apache's project catalog http://projects.apache.org/
> --
>
> Key: TOMAHAWK-528
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-528
> Project: MyFaces Tomahawk
>  Issue Type: Task
>Reporter: Paul Spencer
>Assignee: Hazem Saleh
> Fix For: 1.1.7-SNAPSHOT
>
> Attachments: doap_Tomahawk.rdf
>
>
> This project not listed in Apache's project catalog 
> http://projects.apache.org/. It needs to be added

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

[jira] Resolved: (TOMAHAWK-1230) Excel Export Control uses HTTP get request, which should avoid restore view phase, thus the DataTable will be unavailable.

[Hazem Saleh (JIRA)]

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

Hazem Saleh resolved TOMAHAWK-1230.
---

Resolution: Fixed

I resolved this after making the .

> Excel Export Control uses HTTP get request, which should avoid restore view 
> phase, thus the DataTable will be unavailable.
> --
>
> Key: TOMAHAWK-1230
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1230
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>Affects Versions: 1.1.5, 1.1.6
> Environment: Any
>Reporter: Chris Hornsey
>Assignee: Hazem Saleh
>
> I was recently debugging the excelExport component and phaseListener.  A core 
> requirement of this component is that the user clicks the link created by the 
> component and the browser will send a get request to reopen the page.  The 
> phase listener will fire on the restore view phase, and write the excel 
> representation of the table to the response prior to the response being 
> written to the client.
> According to the JSF spec, if the JSF handler receives a get request from a 
> client it should bypass recreating the component tree during the restore view 
> phase and go directly to the render response phase since clearly nothing has 
> changed in the view.  When this happens the phase listener will throw a null 
> pointer exception due to the fact that the component can not be retrieved 
> from the view since the view will not be recreated until the response is 
> rendered.

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

[jira] Reopened: (TOMAHAWK-768) t:datascroller and sort headers don't work with ajax4jsf

[Hazem Saleh (JIRA)]

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

Hazem Saleh reopened TOMAHAWK-768:
--


> t:datascroller and sort headers don't work with ajax4jsf
> 
>
> Key: TOMAHAWK-768
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-768
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: Data Scroller, Sort Header
>Affects Versions: 1.1.3
>Reporter: Popcorn
>Assignee: Hazem Saleh
> Attachments: HtmlDataScrollerRendererFixedForAjax.java
>
>
> The datascroller and sort headers stop working inside an ajax-rendered area 
> with Ajax4jsf. The components need to be patched.
> For details, see this link:
> http://marc.theaimsgroup.com/?l=myfaces-user&m=116237031123948&w=2

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

[jira] Reopened: (TOMAHAWK-1272) GMap component

[Hazem Saleh (JIRA)]

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

Hazem Saleh reopened TOMAHAWK-1272:
---


> GMap component
> --
>
> Key: TOMAHAWK-1272
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1272
> Project: MyFaces Tomahawk
>  Issue Type: New Feature
>Reporter: Hazem Saleh
>Assignee: Hazem Saleh
>
> A component that integrates GMap with Tomahawk.

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

Re: [jira] Updated: (TOMAHAWK-768) t:datascroller and sort headers don't work with ajax4jsf

[Hazem Saleh]

OK then I will leave them open.
Thanks.

On Wed, Jul 9, 2008 at 5:33 PM, [EMAIL PROTECTED] <
[EMAIL PROTECTED]> wrote:

> Hi Hazem,
>
> AFAIK we don't usually bother to resolve issues as "later". That's just a
> nuisance because then they need to be reopened after the release.
>
> Regards, Simon
>
> Hazem Saleh (JIRA) schrieb:
>
>  [
>> https://issues.apache.org/jira/browse/TOMAHAWK-768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>>
>> Hazem Saleh updated TOMAHAWK-768:
>> -
>>
>>Resolution: Later
>>Status: Resolved  (was: Patch Available)
>>
>>
>>
>>> t:datascroller and sort headers don't work with ajax4jsf
>>> 
>>>
>>>Key: TOMAHAWK-768
>>>URL: https://issues.apache.org/jira/browse/TOMAHAWK-768
>>>Project: MyFaces Tomahawk
>>> Issue Type: Bug
>>> Components: Data Scroller, Sort Header
>>>   Affects Versions: 1.1.3
>>>   Reporter: Popcorn
>>>   Assignee: Hazem Saleh
>>>Attachments: HtmlDataScrollerRendererFixedForAjax.java
>>>
>>>
>>> The datascroller and sort headers stop working inside an ajax-rendered
>>> area with Ajax4jsf. The components need to be patched.
>>> For details, see this link:
>>> http://marc.theaimsgroup.com/?l=myfaces-user&m=116237031123948&w=2
>>>
>>>
>>
>>
>>
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [jira] Updated: (TOMAHAWK-768) t:datascroller and sort headers don't work with ajax4jsf

[[EMAIL PROTECTED]]

Hi Hazem,

AFAIK we don't usually bother to resolve issues as "later". That's just 
a nuisance because then they need to be reopened after the release.


Regards, Simon

Hazem Saleh (JIRA) schrieb:

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

Hazem Saleh updated TOMAHAWK-768:
-

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

  

t:datascroller and sort headers don't work with ajax4jsf


Key: TOMAHAWK-768
URL: https://issues.apache.org/jira/browse/TOMAHAWK-768
Project: MyFaces Tomahawk
 Issue Type: Bug
 Components: Data Scroller, Sort Header
   Affects Versions: 1.1.3
   Reporter: Popcorn
   Assignee: Hazem Saleh
Attachments: HtmlDataScrollerRendererFixedForAjax.java


The datascroller and sort headers stop working inside an ajax-rendered area 
with Ajax4jsf. The components need to be patched.
For details, see this link:
http://marc.theaimsgroup.com/?l=myfaces-user&m=116237031123948&w=2



  

[jira] Updated: (TOMAHAWK-768) t:datascroller and sort headers don't work with ajax4jsf

[Hazem Saleh (JIRA)]

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

Hazem Saleh updated TOMAHAWK-768:
-

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

> t:datascroller and sort headers don't work with ajax4jsf
> 
>
> Key: TOMAHAWK-768
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-768
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: Data Scroller, Sort Header
>Affects Versions: 1.1.3
>Reporter: Popcorn
>Assignee: Hazem Saleh
> Attachments: HtmlDataScrollerRendererFixedForAjax.java
>
>
> The datascroller and sort headers stop working inside an ajax-rendered area 
> with Ajax4jsf. The components need to be patched.
> For details, see this link:
> http://marc.theaimsgroup.com/?l=myfaces-user&m=116237031123948&w=2

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

[jira] Resolved: (TOMAHAWK-1272) GMap component

[Hazem Saleh (JIRA)]

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

Hazem Saleh resolved TOMAHAWK-1272.
---

Resolution: Later

will do in the next release.

> GMap component
> --
>
> Key: TOMAHAWK-1272
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-1272
> Project: MyFaces Tomahawk
>  Issue Type: New Feature
>Reporter: Hazem Saleh
>Assignee: Hazem Saleh
>
> A component that integrates GMap with Tomahawk.

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

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Hazem Saleh]

Mario, Could you please open jira issues on the defects you found during
your work with
.

Thank you.

On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:

> Hi!
>
>  s:xmlTemplate
>>
> Dont know much, not to say "nothing", about that.
>
>  s:pprPanelGroup (is this component ready? it could be good but I don't
>> know if there is any objection).
>>
> I do not think that pprPanelGroup is ready for a release, there are some
> things still missing and sometimes it stopps working.
> Unfortunately, I have to say I am switching away from pprPanelGroup to a4j
> with richfaces.
> I just have no time to look into pprPanelGroup ...
>
> Ciao,
> Mario
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Hazem Saleh]

I will also work on http://issues.apache.org/jira/browse/TOMAHAWK-1122.

On Wed, Jul 9, 2008 at 4:52 PM, Hazem Saleh <[EMAIL PROTECTED]> wrote:

> Hi Leonardo,
>
> I will dig at the  issues in the nearest free time
> slot to promote it.
> Thanks!
>
>
> On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:
>
>> Hi!
>>
>>  s:xmlTemplate
>>>
>> Dont know much, not to say "nothing", about that.
>>
>>  s:pprPanelGroup (is this component ready? it could be good but I don't
>>> know if there is any objection).
>>>
>> I do not think that pprPanelGroup is ready for a release, there are some
>> things still missing and sometimes it stopps working.
>> Unfortunately, I have to say I am switching away from pprPanelGroup to a4j
>> with richfaces.
>> I just have no time to look into pprPanelGroup ...
>>
>> Ciao,
>> Mario
>>
>>
>
>
> --
> Hazem Ahmed Saleh Ahmed
> http://www.jroller.com/page/HazemBlog




-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

Re: [tomahawk] Is there any task left to make a release of tomahawk?

[Hazem Saleh]

Hi Leonardo,

I will dig at the  issues in the nearest free time
slot to promote it.
Thanks!

On Wed, Jul 9, 2008 at 1:39 AM, Mario Ivankovits <[EMAIL PROTECTED]> wrote:

> Hi!
>
>  s:xmlTemplate
>>
> Dont know much, not to say "nothing", about that.
>
>  s:pprPanelGroup (is this component ready? it could be good but I don't
>> know if there is any objection).
>>
> I do not think that pprPanelGroup is ready for a release, there are some
> things still missing and sometimes it stopps working.
> Unfortunately, I have to say I am switching away from pprPanelGroup to a4j
> with richfaces.
> I just have no time to look into pprPanelGroup ...
>
> Ciao,
> Mario
>
>


-- 
Hazem Ahmed Saleh Ahmed
http://www.jroller.com/page/HazemBlog

[jira] Updated: (TOMAHAWK-922) JSF-1.2: JspTilesViewHandlerImpl

[JIRA]

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

Rafael Fernández updated TOMAHAWK-922:
--

Status: Patch Available  (was: Open)

> JSF-1.2: JspTilesViewHandlerImpl
> 
>
> Key: TOMAHAWK-922
> URL: https://issues.apache.org/jira/browse/TOMAHAWK-922
> Project: MyFaces Tomahawk
>  Issue Type: Bug
>  Components: Tiles
>Affects Versions: 1.1.5-SNAPSHOT
> Environment: MyFaces Tomahawk SVN HEAD + JSF-1.2_03 (Reference 
> implementation) + JDK-1.5.0_11 + Tomcat-6.0.10
>Reporter: Jesper Pedersen
>
> The JspTilesViewHandlerImpl doesn't work under JSF-1.2 (RI) as it doesn't 
> deliver any output.
> Steps:
> 1) Get myfaces-example-tiles-1.1.5-SNAPSHOT.war
> 2) Replace MyFaces-Core with JSF-1.2 (RI) in WEB-INF/lib
> 3) Deploy on Tomcat-6.0.10
> 4) Go to http://localhost:8080/myfaces-example-tiles-1.1.5-SNAPSHOT/
> Generated HTML:
> 
> 
>   
>   Myfaces - Tiles
>   
> 
> 
> Basically I'm unable to use Tomahawk under JSF-1.2 currently, so any pointers 
> on how to fix this issue or to provide more information would be great.

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

[jira] Commented: (TRINIDAD-1152) Improve XHTML support in Trinidad

[JIRA]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611981#action_12611981
 ] 

Matthias Weßendorf commented on TRINIDAD-1152:
--

Part of the fix is to provide OO-style helper to check for the form / 
contentType to get the desired FORM element

> Improve XHTML support in Trinidad
> -
>
> Key: TRINIDAD-1152
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1152
> Project: MyFaces Trinidad
>  Issue Type: Improvement
>Affects Versions:  1.0.8-core,  1.2.8-core
>Reporter: Matthias Weßendorf
>Assignee: Matthias Weßendorf
>
> Currently Trinidad is not 100% supporting XHTML.
> See these issues:
> TRINIDAD-818
> TRINIDAD-1139
> Another problem is, that Trinidad uses document.forms property, which works 
> in only some cases:
> -mime_type is "application/xhtml+xml"
> it doesn't work when mime type is "application/xml" or "text/xml", ergo when 
> document send as *xml* to the browser.
> In that case, the getElementsByTagName() provides help...
> See here as well:
> http://blog.rd2inc.com/archives/2005/02/11/xhtml-and-the-applicationxhtmlxml-mime-type/

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

[jira] Commented: (TRINIDAD-1152) Improve XHTML support in Trinidad

[JIRA]

[ 
https://issues.apache.org/jira/browse/TRINIDAD-1152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12611980#action_12611980
 ] 

Matthias Weßendorf commented on TRINIDAD-1152:
--

due to testing reasons, this will arrive *after* a Trinidad 1.x.9 release.

> Improve XHTML support in Trinidad
> -
>
> Key: TRINIDAD-1152
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1152
> Project: MyFaces Trinidad
>  Issue Type: Improvement
>Affects Versions:  1.0.8-core,  1.2.8-core
>Reporter: Matthias Weßendorf
>Assignee: Matthias Weßendorf
>
> Currently Trinidad is not 100% supporting XHTML.
> See these issues:
> TRINIDAD-818
> TRINIDAD-1139
> Another problem is, that Trinidad uses document.forms property, which works 
> in only some cases:
> -mime_type is "application/xhtml+xml"
> it doesn't work when mime type is "application/xml" or "text/xml", ergo when 
> document send as *xml* to the browser.
> In that case, the getElementsByTagName() provides help...
> See here as well:
> http://blog.rd2inc.com/archives/2005/02/11/xhtml-and-the-applicationxhtmlxml-mime-type/

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

[jira] Created: (TRINIDAD-1152) Improve XHTML support in Trinidad

[JIRA]

Improve XHTML support in Trinidad
-

 Key: TRINIDAD-1152
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1152
 Project: MyFaces Trinidad
  Issue Type: Improvement
Affects Versions:  1.2.8-core,  1.0.8-core
Reporter: Matthias Weßendorf
Assignee: Matthias Weßendorf


Currently Trinidad is not 100% supporting XHTML.
See these issues:
TRINIDAD-818
TRINIDAD-1139

Another problem is, that Trinidad uses document.forms property, which works in 
only some cases:
-mime_type is "application/xhtml+xml"

it doesn't work when mime type is "application/xml" or "text/xml", ergo when 
document send as *xml* to the browser.
In that case, the getElementsByTagName() provides help...

See here as well:

http://blog.rd2inc.com/archives/2005/02/11/xhtml-and-the-applicationxhtmlxml-mime-type/

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

[jira] Created: (TRINIDAD-1151) PPR not working if cdata tags are added to scripts

[Balaji Vishwanath (JIRA)]

PPR not working if cdata tags are added to scripts
--

 Key: TRINIDAD-1151
 URL: https://issues.apache.org/jira/browse/TRINIDAD-1151
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 1.0.7-core
 Environment: Windows 2k3
Reporter: Balaji Vishwanath
Priority: Critical


Hi

We have a ReponseWriter implementation which replaces the contents within the 
scripts of the rendered page with cdata tags to escape validation. The output 
of scripts for a trinidad page in doing so would be something like shown below 
 

/*  */



/*  */


Having done this the PPR requests in that page no more works.

But the original output of scripts for the same trinidad page would be 
something like below, which works for the PPR request on that page.

_submitFormCheck();

var _pprUpDatemode=false;function 
_adfspu(f,v,e,s,o){_pprUpdateMode=true;if(!o)o=new 
Object();if(e)o.event=e;if(s)o.source=s;_submitPartialChange(f,v,o);}

Please let me know if there is any workaround so that I can still retain my 
escape tags in scripts and get the PPR working.

Regards
Balaji

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

[jira] Updated: (TRINIDAD-1149) ApacheChart.js resource loading problems

[JIRA]

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

Matthias Weßendorf updated TRINIDAD-1149:
-

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

Thanks to Andy Schwartz for his patch.

> ApacheChart.js resource loading problems
> 
>
> Key: TRINIDAD-1149
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1149
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Archetype
>Affects Versions:  1.0.8-core,  1.2.8-core
>Reporter: Andy Schwartz
>Assignee: Matthias Weßendorf
> Fix For: 1.0.9-core, 1.2.9-core
>
> Attachments: TRINIDAD-1149-trunk-1_2_x.patch
>
>
> As part of the fix for the following bug:
> TRINIDAD-1083 Chart component does not render anymore in 1.1 and 1.2 trunk
> We introduced the ApacheChart.js code into the Trinidad "common" JavaScript 
> library.  This resulted in two new problems:
> 1. The size of the common library increased by 122K (when using obfuscated 
> JS, more when using debug JS). 
> 2. When running with DEBUG_JAVASCRIPT set to "false", the ApacheChart.js code 
> is actually loaded two times - once with the common library, and a second 
> time when the ApacheChart.js is requested separately. 
> As a result, when running in non-JS-debug mode, we now load an extra 244K of 
> JS code on every page.   This is unacceptable, since it negatively impacts 
> performance of all Trinidad pages/applications, even those which do not use 
> the chart component.
> There is a third problem which existed before the fix for TRINIDAD-1083, and 
> still exists today:
> 3. When running with DEBUG_JAVASCRIPT set to "true", the direct request for 
> the debug version of the ApacheChart.js library fails with a 404 error.
> Looking back at TRINIDAD-1083, the correct fix would have been to address 
> issue #3 - ie. to make sure that our resource loader actually successfully 
> handles the request for the debug version of the ApacheChart.js library.
> After some debugging, I was able to figure out why this request was failing.  
> The following comment from my soon to be submitted patch explains:
>   // LibraryScriptlet prefixes debug JS libraries with the prefix
>   // "Debug".  So, for example,  the "Foo.js" library ends up being
>   // referred to via an URL of the form "/jsLibs/DebugFoo.js".
>   // Unfortunately, this is out of sync with reality, since our
>   // JS libraries actually live under a "jsLibsDebug" directory,
>   // ie. the debug "Foo.js" lives at "META-INF/adf/jsLibsDebug/Foo.js".
>   // As a result, CoreClassLoaderResourceLoader fails to locate
>   // scripts that are rendered via a LibraryScriptlet.
>   //
>   // To work around this problem, this code converts paths of the
>   // form "jsLibs/Debug" to "jsLibsDebug/", which allows our
>   // library look ups to succeed.
> Unforunately, I haven't been able to figure out when this problem was 
> originally introduced, or how this was actually working in the past.

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

[jira] Resolved: (TRINIDAD-1150) Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized renderkit

[JIRA]

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

Matthias Weßendorf resolved TRINIDAD-1150.
--

   Resolution: Fixed
Fix Version/s: 1.2.9-core

thanks for the patch, Yee-Wah Lee.

> Problem upgrading to version 1.0.5 (or 2.0.8) of trinidad with customized 
> renderkit
> ---
>
> Key: TRINIDAD-1150
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1150
> Project: MyFaces Trinidad
>  Issue Type: Bug
>  Components: Components
>Reporter: Yee-Wah Lee
>Assignee: Matthias Weßendorf
> Fix For: 1.2.9-core
>
> Attachments: trin11_797_deferredRenderers.patch, trin12_1150.patch
>
>
> Sample error message when trying to upgrade from Trinidad 1.2.1 to 1.2.8, and 
> when user has own renderkit.
> SEVERE: Exception sending context initialized event to listener instance of
> class com.sun.faces.config.ConfigureListener
> java.lang.ExceptionInInitializerError
> at
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelfWithKey(Scriptlet.java:163)
> at
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.Scriptlet.registerSelf(Scriptlet.java:92)
> ...
> Caused by: java.lang.NullPointerException
> at
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.LocaleInfoScriptlet.getSupportedLocaleVariant(LocaleInfoScriptlet.java:168)
> at
> org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.jsLibs.NamedLocaleInfoScriptlet.(NamedLocaleInfoScriptlet.java:62)
> ...
> This was caused by the patch for Trinidad-797 which assumed delay loading of 
> renders, which the core trinidad renderkit implemented.

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

[jira] Resolved: (TRINIDAD-617) Fix MVariableResolver to use Calendar APIs instead of deprecated Date APIs

[JIRA]

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

Matthias Weßendorf resolved TRINIDAD-617.
-

Resolution: Won't Fix

> Fix MVariableResolver to use Calendar APIs instead of deprecated Date APIs
> --
>
> Key: TRINIDAD-617
> URL: https://issues.apache.org/jira/browse/TRINIDAD-617
> Project: MyFaces Trinidad
>  Issue Type: Test
>Affects Versions: 1.0.1-incubating-core-SNAPSHOT
>Reporter: Yee-Wah Lee
>Priority: Trivial
> Attachments: ChooseDateRenderer.patch, trinidad-impl.patch, 
> trinidad-impl.patch
>
>
> MVariableResolver is used by the ChooseDateRenderer tests to get min, max and 
> midDate values. This is so the tests always generate the same output. 
> However, the APIs used in the code are the deprecated Date constructors. I 
> will replace them with the suggested GregorianCalendar equivalents.  
> Patch file contains changes to MVariableResolver.java (new Calendar calls, 
> and some import cleanups) and the corresponding chooseDate golden files

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