Partial Page Rendering for tomahawk

[Ernst Fastl <er...@gmail.com>]

Hello everyone,

After verifying the patches I send him Catalin was so kind and commited the
new sandbox component called PPRPanelGroup to the sandbox. With this
component you can souround areas of a page which you want to be updated
by AJAX calls. You just specify in the partialTriggers-Attribute a
comma-seperated
List of Ids of componenst (e.g. buttons) which trigger this partial update.

This is a initial commit so it is not yet well tested and there are
still a lot of
things to do, but if anyone wants to start playing around with it and making
suggestions for improvements I would be thankful for some feedback.

kind regards

Ernst

Re: Partial Page Rendering for tomahawk

[Mario Ivankovits <ma...@ops.co.at>]

Hi all!

> This is a initial commit so it is not yet well tested and there are
> still a lot of
> things to do, but if anyone wants to start playing around with it and
> making
> suggestions for improvements I would be thankful for some feedback.
JFYI - I've started to try to use it in our application, still, there
are some problems I try to figure out and send a patch to Ernst through
pm then.


Ciao,
Mario

Re: Partial Page Rendering for tomahawk

[Cagatay Civici <ca...@gmail.com>]

Hi,

Well, sandbox or not. I missed the discussion. Remember client side
> validation stuff?
> That was a good thread. Or the "s:secureTag" thread? These two were
> much more "open development" than here, I guess. Maybe that's all I
> missed here. But to me this particular commit *smells*. Sorry, but
> that's my point.


As the guy who started these discussions, I also believe that open
discussions are very important before deciding an action. Other than the
vital points already mentioned in this thread, open discussions is a nice
way to get the ideas of other committers about the design, code and etc.

Cagatay

On 8/23/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> Martin,
>
> glad to hear that you are concerned about that too.
> We should ensure for the future, that the new developers understand
> how the ASF works and that they should consult the the list, in case
> of  ... ;)
>
> I fixed the svn props and build now the code
> for a quick review.
>
> I think Ernst / Catalin learned their lection.
> Finally thx for the contribution.
>
> and let's move over to a pure discussion thread, if needed ;)
>
> -Matthias
>
> On 8/22/06, Martin Marinschek <ma...@gmail.com> wrote:
> > Matthias, you're absolutely right - I'm just as concerned as you about
> > offline development, and asked Ernst several times to engage in an
> > discussion on the mailing list.
> >
> > He did so in the beginning, but then ended up going back to his desk
> > to finish off his first draft of what the PPR support could look like
> > client-side (with a very small server side implementation alongside).
> > This is what was committed to the sandbox just now.
> >
> > My personal best plan would have been to start a discussion again on
> > these accomplishments as soon as he had them done and ready for a
> > review, and well, I wasn't asked (nor could be asked, cause I am
> > offline for giving a JSF training) before the commit happened. Shortly
> > from wanting to excuse the guys, I'll offer some further explanation -
> > the Google SoC program is about to end shortly, and this is why Ernst
> > and Catalin might have time-pressured to get the code in the sandbox
> > to be able to discuss on it.
> >
> > In any case, I think that both Catalin and Ernst will have enough to
> > read about in this thread, and will make sure that something like this
> > will not happen in the future again. Especially Catalin needs to take
> > more care here - as a committer, you are the gatekeeper for what
> > foreign code enters the source base and what not. Catalin, can you
> > make sure that all of Wendy's objections are addressed? I tried to
> > address some of them, but didn't get to propstyle-settings, e.g.
> >
> > And, Ernst, fax your ICLA out - ASAP.
> >
> > And now, one final statement: Ernst, thank you very much for your
> > efforts with regards to AJAX and PPR in tomahawk. I strongly believe
> > this will be an important, much used feature of tomahawk many users
> > will just love, and I do think your implementation is very good, but
> > let's carry on the discussion on this on another thread.
> >
> > regards,
> >
> > Martin
> >
> > On 8/23/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > On 8/22/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > > Hi Matthias!
> > > > > The sort of "offline" development. Sending offline a patch to a
> > > > > committer for letting him commit the stuff is to me a -1. Looks
> like a
> > > > > "bypass".
> > > > Do you propose to use jira as mini-incubator?
> > > > I am not sure this is what it is meant for.
> > >
> > > na, that's not the idea behind this mail.
> > > What I miss in this case is the openess of the discussion. There was
> no.
> > > Maybe sb of us here had been interested. Maybe not! Not a big deal to
> > > start a thread and upload new features (or new components) to jira.
> > > Lot's of users do that.
> > >
> > > > In this case it was committed to the sandbox, no? I like the idea to
> see
> > > > the "sandbox" as incubator even more, we are still free to remove
> stuff,
> > > > so this is not against "open development"
> > >
> > > Well, sandbox or not. I missed the discussion. Remember client side
> > > validation stuff?
> > > That was a good thread. Or the "s:secureTag" thread? These two were
> > > much more "open development" than here, I guess. Maybe that's all I
> > > missed here. But to me this particular commit *smells*. Sorry, but
> > > that's my point.
> > >
> > > If you compare sandbox w/ incubator you should say, that there
> > > (incubator) is also a PMC behind which decides what should go into the
> > > incubator or not.
> > >
> > > Sure, we can remove that afterwards, but that's not needed if the
> > > community process is working. Like incubator I am speaking here of the
> > > development community.
> > >
> > > > I think, for this (Google SoC) project, where Ernst worked together
> > > > closely with Martin it is good enough, and that way it is easier to
> > > > check the code quality AND if it works. If I had to trash my trunk
> with
> > > > its patch I suspect I'd check this code (given the pressure I
> currently
> > > > have)
> > >
> > > Yes, that's for the Google SoC. It is cool that he worked closely with
> > > Martin. I like that. But I don't see the point why using jira is a
> > > show stopper. With a patch to jira it's also possible to look at the
> > > quality and the component itself. I don't doubt about the quality. I
> > > am just worried about the process ;)
> > >
> > > > For sure, it was not the best way how this code found its way into
> > > > myfaces, but let it be and we'll ensure for the future that it will
> go
> > > > better.
> > >
> > > I hope so. I am not planing to remove this. Just giving a heads-up
> > > about the totaly wrong way (IMO).
> > >
> > > -Matthias
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: Partial Page Rendering for tomahawk

[Matthias Wessendorf <ma...@apache.org>]

Martin,

glad to hear that you are concerned about that too.
We should ensure for the future, that the new developers understand
how the ASF works and that they should consult the the list, in case
of  ... ;)

I fixed the svn props and build now the code
for a quick review.

I think Ernst / Catalin learned their lection.
Finally thx for the contribution.

and let's move over to a pure discussion thread, if needed ;)

-Matthias

On 8/22/06, Martin Marinschek <ma...@gmail.com> wrote:
> Matthias, you're absolutely right - I'm just as concerned as you about
> offline development, and asked Ernst several times to engage in an
> discussion on the mailing list.
>
> He did so in the beginning, but then ended up going back to his desk
> to finish off his first draft of what the PPR support could look like
> client-side (with a very small server side implementation alongside).
> This is what was committed to the sandbox just now.
>
> My personal best plan would have been to start a discussion again on
> these accomplishments as soon as he had them done and ready for a
> review, and well, I wasn't asked (nor could be asked, cause I am
> offline for giving a JSF training) before the commit happened. Shortly
> from wanting to excuse the guys, I'll offer some further explanation -
> the Google SoC program is about to end shortly, and this is why Ernst
> and Catalin might have time-pressured to get the code in the sandbox
> to be able to discuss on it.
>
> In any case, I think that both Catalin and Ernst will have enough to
> read about in this thread, and will make sure that something like this
> will not happen in the future again. Especially Catalin needs to take
> more care here - as a committer, you are the gatekeeper for what
> foreign code enters the source base and what not. Catalin, can you
> make sure that all of Wendy's objections are addressed? I tried to
> address some of them, but didn't get to propstyle-settings, e.g.
>
> And, Ernst, fax your ICLA out - ASAP.
>
> And now, one final statement: Ernst, thank you very much for your
> efforts with regards to AJAX and PPR in tomahawk. I strongly believe
> this will be an important, much used feature of tomahawk many users
> will just love, and I do think your implementation is very good, but
> let's carry on the discussion on this on another thread.
>
> regards,
>
> Martin
>
> On 8/23/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > On 8/22/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > > Hi Matthias!
> > > > The sort of "offline" development. Sending offline a patch to a
> > > > committer for letting him commit the stuff is to me a -1. Looks like a
> > > > "bypass".
> > > Do you propose to use jira as mini-incubator?
> > > I am not sure this is what it is meant for.
> >
> > na, that's not the idea behind this mail.
> > What I miss in this case is the openess of the discussion. There was no.
> > Maybe sb of us here had been interested. Maybe not! Not a big deal to
> > start a thread and upload new features (or new components) to jira.
> > Lot's of users do that.
> >
> > > In this case it was committed to the sandbox, no? I like the idea to see
> > > the "sandbox" as incubator even more, we are still free to remove stuff,
> > > so this is not against "open development"
> >
> > Well, sandbox or not. I missed the discussion. Remember client side
> > validation stuff?
> > That was a good thread. Or the "s:secureTag" thread? These two were
> > much more "open development" than here, I guess. Maybe that's all I
> > missed here. But to me this particular commit *smells*. Sorry, but
> > that's my point.
> >
> > If you compare sandbox w/ incubator you should say, that there
> > (incubator) is also a PMC behind which decides what should go into the
> > incubator or not.
> >
> > Sure, we can remove that afterwards, but that's not needed if the
> > community process is working. Like incubator I am speaking here of the
> > development community.
> >
> > > I think, for this (Google SoC) project, where Ernst worked together
> > > closely with Martin it is good enough, and that way it is easier to
> > > check the code quality AND if it works. If I had to trash my trunk with
> > > its patch I suspect I'd check this code (given the pressure I currently
> > > have)
> >
> > Yes, that's for the Google SoC. It is cool that he worked closely with
> > Martin. I like that. But I don't see the point why using jira is a
> > show stopper. With a patch to jira it's also possible to look at the
> > quality and the component itself. I don't doubt about the quality. I
> > am just worried about the process ;)
> >
> > > For sure, it was not the best way how this code found its way into
> > > myfaces, but let it be and we'll ensure for the future that it will go
> > > better.
> >
> > I hope so. I am not planing to remove this. Just giving a heads-up
> > about the totaly wrong way (IMO).
> >
> > -Matthias
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Partial Page Rendering for tomahawk

[Martin Marinschek <ma...@gmail.com>]

Matthias, you're absolutely right - I'm just as concerned as you about
offline development, and asked Ernst several times to engage in an
discussion on the mailing list.

He did so in the beginning, but then ended up going back to his desk
to finish off his first draft of what the PPR support could look like
client-side (with a very small server side implementation alongside).
This is what was committed to the sandbox just now.

My personal best plan would have been to start a discussion again on
these accomplishments as soon as he had them done and ready for a
review, and well, I wasn't asked (nor could be asked, cause I am
offline for giving a JSF training) before the commit happened. Shortly
from wanting to excuse the guys, I'll offer some further explanation -
the Google SoC program is about to end shortly, and this is why Ernst
and Catalin might have time-pressured to get the code in the sandbox
to be able to discuss on it.

In any case, I think that both Catalin and Ernst will have enough to
read about in this thread, and will make sure that something like this
will not happen in the future again. Especially Catalin needs to take
more care here - as a committer, you are the gatekeeper for what
foreign code enters the source base and what not. Catalin, can you
make sure that all of Wendy's objections are addressed? I tried to
address some of them, but didn't get to propstyle-settings, e.g.

And, Ernst, fax your ICLA out - ASAP.

And now, one final statement: Ernst, thank you very much for your
efforts with regards to AJAX and PPR in tomahawk. I strongly believe
this will be an important, much used feature of tomahawk many users
will just love, and I do think your implementation is very good, but
let's carry on the discussion on this on another thread.

regards,

Martin

On 8/23/06, Matthias Wessendorf <ma...@apache.org> wrote:
> On 8/22/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi Matthias!
> > > The sort of "offline" development. Sending offline a patch to a
> > > committer for letting him commit the stuff is to me a -1. Looks like a
> > > "bypass".
> > Do you propose to use jira as mini-incubator?
> > I am not sure this is what it is meant for.
>
> na, that's not the idea behind this mail.
> What I miss in this case is the openess of the discussion. There was no.
> Maybe sb of us here had been interested. Maybe not! Not a big deal to
> start a thread and upload new features (or new components) to jira.
> Lot's of users do that.
>
> > In this case it was committed to the sandbox, no? I like the idea to see
> > the "sandbox" as incubator even more, we are still free to remove stuff,
> > so this is not against "open development"
>
> Well, sandbox or not. I missed the discussion. Remember client side
> validation stuff?
> That was a good thread. Or the "s:secureTag" thread? These two were
> much more "open development" than here, I guess. Maybe that's all I
> missed here. But to me this particular commit *smells*. Sorry, but
> that's my point.
>
> If you compare sandbox w/ incubator you should say, that there
> (incubator) is also a PMC behind which decides what should go into the
> incubator or not.
>
> Sure, we can remove that afterwards, but that's not needed if the
> community process is working. Like incubator I am speaking here of the
> development community.
>
> > I think, for this (Google SoC) project, where Ernst worked together
> > closely with Martin it is good enough, and that way it is easier to
> > check the code quality AND if it works. If I had to trash my trunk with
> > its patch I suspect I'd check this code (given the pressure I currently
> > have)
>
> Yes, that's for the Google SoC. It is cool that he worked closely with
> Martin. I like that. But I don't see the point why using jira is a
> show stopper. With a patch to jira it's also possible to look at the
> quality and the component itself. I don't doubt about the quality. I
> am just worried about the process ;)
>
> > For sure, it was not the best way how this code found its way into
> > myfaces, but let it be and we'll ensure for the future that it will go
> > better.
>
> I hope so. I am not planing to remove this. Just giving a heads-up
> about the totaly wrong way (IMO).
>
> -Matthias
>


-- 

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Partial Page Rendering for tomahawk

[Matthias Wessendorf <ma...@apache.org>]

On 8/22/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> Hi Matthias!
> > The sort of "offline" development. Sending offline a patch to a
> > committer for letting him commit the stuff is to me a -1. Looks like a
> > "bypass".
> Do you propose to use jira as mini-incubator?
> I am not sure this is what it is meant for.

na, that's not the idea behind this mail.
What I miss in this case is the openess of the discussion. There was no.
Maybe sb of us here had been interested. Maybe not! Not a big deal to
start a thread and upload new features (or new components) to jira.
Lot's of users do that.

> In this case it was committed to the sandbox, no? I like the idea to see
> the "sandbox" as incubator even more, we are still free to remove stuff,
> so this is not against "open development"

Well, sandbox or not. I missed the discussion. Remember client side
validation stuff?
That was a good thread. Or the "s:secureTag" thread? These two were
much more "open development" than here, I guess. Maybe that's all I
missed here. But to me this particular commit *smells*. Sorry, but
that's my point.

If you compare sandbox w/ incubator you should say, that there
(incubator) is also a PMC behind which decides what should go into the
incubator or not.

Sure, we can remove that afterwards, but that's not needed if the
community process is working. Like incubator I am speaking here of the
development community.

> I think, for this (Google SoC) project, where Ernst worked together
> closely with Martin it is good enough, and that way it is easier to
> check the code quality AND if it works. If I had to trash my trunk with
> its patch I suspect I'd check this code (given the pressure I currently
> have)

Yes, that's for the Google SoC. It is cool that he worked closely with
Martin. I like that. But I don't see the point why using jira is a
show stopper. With a patch to jira it's also possible to look at the
quality and the component itself. I don't doubt about the quality. I
am just worried about the process ;)

> For sure, it was not the best way how this code found its way into
> myfaces, but let it be and we'll ensure for the future that it will go
> better.

I hope so. I am not planing to remove this. Just giving a heads-up
about the totaly wrong way (IMO).

-Matthias

Re: Partial Page Rendering for tomahawk

[Mario Ivankovits <ma...@ops.co.at>]

Hi Matthias!
> The sort of "offline" development. Sending offline a patch to a
> committer for letting him commit the stuff is to me a -1. Looks like a
> "bypass".
Do you propose to use jira as mini-incubator?
I am not sure this is what it is meant for.

In this case it was committed to the sandbox, no? I like the idea to see
the "sandbox" as incubator even more, we are still free to remove stuff,
so this is not against "open development"

I think, for this (Google SoC) project, where Ernst worked together
closely with Martin it is good enough, and that way it is easier to
check the code quality AND if it works. If I had to trash my trunk with
its patch I suspect I'd check this code (given the pressure I currently
have)

For sure, it was not the best way how this code found its way into
myfaces, but let it be and we'll ensure for the future that it will go
better.


Beside this: I have a bad need for such a kind of stuff currently (so I
am biased ;-) ), so I'll check it before I go on with ajax4jsf or
ajaxAnywhere - I'll start in the next two days. (maybe today)

Ciao,
Mario

Re: Partial Page Rendering for tomahawk

[Matthias Wessendorf <ma...@apache.org>]

> > I am not concerned about the icla or not


> As a PMC member for Apache MyFaces, you *should* be concerned about this.
...

Yes I agree! But that was not questionalbe (from my side).

I think that "I am not concerned about the icla or not" was wrong understood.
sure I care about the ICLA stuff, but I am pointing out to another issue here.

The sort of "offline" development. Sending offline a patch to a
committer for letting him commit the stuff is to me a -1. Looks like a
"bypass".
I mean how can a discussion come up on stuff like that? Only when the
commit is done?
That's not what I understand from "open development". Discussion,
after inspecting the committed code? No, to me. Creating an issue on
jira is important (not "only" b/c of the licensing).

The lack of license headers in java files needs to be fixed. I hope
it's now more clear, what I am concerned about...

(be sure about the iCLA/license header too). But offline development
is bad, to me.

-Matthias

>
>
>
> > I am more concerned about the fact that patches sent offline
> > and not through Jira.
>
>
> Even if they had been, that would not have been sufficient in this case, for
> the reasons outlined above.
>
> > I mean, why ?
>
> Craig McClanahan
>
>
> [1] http://www.apache.org/licenses/
> [2] http://www.apache.org/licenses/icla.txt
>
>
>
> > On 8/22/06, Martin Marinschek < martin.marinschek@gmail.com > wrote:
> > > For a substantial contribution like this, we'll need a CLA on file in
> > > any case (even if the code came in through a jira-issue).
> > >
> > > regards,
> > >
> > > Martin
> > >
> > > On 8/22/06, Wendy Smoak < wsmoak@gmail.com> wrote:
> > > > On 8/22/06, Ernst Fastl < ernst.fastl@gmail.com> wrote:
> > > >
> > > > > Hello everyone,
> > > > >
> > > > > After verifying the patches I send him Catalin was so kind and
> commited the
> > > > > new sandbox component called PPRPanelGroup to the sandbox.
> > > >
> > > > Hi there!  I think that's the commit I just commented on. :)
> > > >
> > > > Matthias already asked if there was a JIRA issue open, which might
> > > > address my concern about whether we have (or need) a contributor
> > > > license agreement [1] for the new code.
> > > >
> > > > [1] http://www.apache.org/licenses/index.html#clas
> > > >
> > > > --
> > > > Wendy
> > > >
> > >
> > >
> > > --
> > >
> > > http://www.irian.at
> > >
> > > Your JSF powerhouse -
> > > JSF Consulting, Development and
> > > Courses in English and German
> > >
> > > Professional Support for Apache MyFaces
> > >
> >
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Partial Page Rendering for tomahawk

[Craig McClanahan <cr...@apache.org>]

On 8/22/06, Matthias Wessendorf <matzew@apache.org > wrote:
>
> I am not concerned about the icla or not


As a PMC member for Apache MyFaces, you *should* be concerned about this.

Part of the responsibility that the ASF Board delegates to  each PMC is to
ensure that all code ultimately included in the project is covered by
appropriate licensing, so that downstream users of Apache software can be
assured that this is the case.  For "patches" included as attachments on a
JIRA issue, we provide a convenient way for the poster to  grant a license
specifically for this patch.  Therefore, sending all patches from
non-committers through JIRA helps create an audit trail, and is therefore a
Good Thing.

However, this will not be considered sufficient for "large" contributions,
where the contributor is also asked to sign an Individual CLA[1].  How large
is "large"?  Clearly, we shouldn't need this for for a three-line patch
submitted through JIRA with the appropriate radio button granting a license
attrached.  But would it have been OK to accept all of Trinidad as a
humongous patch, simply by having someone have checked the button?  Nope ...
that is definitely "large" enough to require more.   A contribution of this
size (multiple source files and associated resources) is definitely at the
point where the "should" in the page referenced below means REALLY REALLY
should.

Is the original author of these classes willing to sign and fax in a
CLA[2]?  If so, that gets us over the first hurdle.  If not, the files
should definitely be removed.

The second problem is one that Wendy pointed out ... lack of license headers
on the source files.  While the details of this policy are currently being
reviewed, standing practice is to use the complete header that you'll see on
all the other MyFaces source files, in its entirety, at the top of every
source file.  As committers, this is something we should look for on
incoming new source files before adding them to the source code repository.
Because these files do not have such headers, they should be removed, and
not re-added until both issues (CLA and license headers) have been
addressed.

The line-endings issue is something that should also be fixed, but it's not
make-or-break to have source code in the repository.  But having these
broken means you'll have to answer to people like Wendy :-).


I am more concerned about the fact that patches sent offline
> and not through Jira.


Even if they had been, that would not have been sufficient in this case, for
the reasons outlined above.

I mean, why ?


Craig McClanahan

[1] http://www.apache.org/licenses/
[2] http://www.apache.org/licenses/icla.txt



On 8/22/06, Martin Marinschek < martin.marinschek@gmail.com > wrote:
> > For a substantial contribution like this, we'll need a CLA on file in
> > any case (even if the code came in through a jira-issue).
> >
> > regards,
> >
> > Martin
> >
> > On 8/22/06, Wendy Smoak < wsmoak@gmail.com> wrote:
> > > On 8/22/06, Ernst Fastl < ernst.fastl@gmail.com> wrote:
> > >
> > > > Hello everyone,
> > > >
> > > > After verifying the patches I send him Catalin was so kind and
> commited the
> > > > new sandbox component called PPRPanelGroup to the sandbox.
> > >
> > > Hi there!  I think that's the commit I just commented on. :)
> > >
> > > Matthias already asked if there was a JIRA issue open, which might
> > > address my concern about whether we have (or need) a contributor
> > > license agreement [1] for the new code.
> > >
> > > [1] http://www.apache.org/licenses/index.html#clas
> > >
> > > --
> > > Wendy
> > >
> >
> >
> > --
> >
> > http://www.irian.at
> >
> > Your JSF powerhouse -
> > JSF Consulting, Development and
> > Courses in English and German
> >
> > Professional Support for Apache MyFaces
> >
>
>
> --
> Matthias Wessendorf
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>

Re: Partial Page Rendering for tomahawk

[Matthias Wessendorf <ma...@apache.org>]

I am not concerned about the icla or not
I am more concerned about the fact that patches sent offline
and not through Jira.

I mean, why ?

On 8/22/06, Martin Marinschek <ma...@gmail.com> wrote:
> For a substantial contribution like this, we'll need a CLA on file in
> any case (even if the code came in through a jira-issue).
>
> regards,
>
> Martin
>
> On 8/22/06, Wendy Smoak <ws...@gmail.com> wrote:
> > On 8/22/06, Ernst Fastl <er...@gmail.com> wrote:
> >
> > > Hello everyone,
> > >
> > > After verifying the patches I send him Catalin was so kind and commited the
> > > new sandbox component called PPRPanelGroup to the sandbox.
> >
> > Hi there!  I think that's the commit I just commented on. :)
> >
> > Matthias already asked if there was a JIRA issue open, which might
> > address my concern about whether we have (or need) a contributor
> > license agreement [1] for the new code.
> >
> > [1] http://www.apache.org/licenses/index.html#clas
> >
> > --
> > Wendy
> >
>
>
> --
>
> http://www.irian.at
>
> Your JSF powerhouse -
> JSF Consulting, Development and
> Courses in English and German
>
> Professional Support for Apache MyFaces
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com

Re: Partial Page Rendering for tomahawk

[Martin Marinschek <ma...@gmail.com>]

For a substantial contribution like this, we'll need a CLA on file in
any case (even if the code came in through a jira-issue).

regards,

Martin

On 8/22/06, Wendy Smoak <ws...@gmail.com> wrote:
> On 8/22/06, Ernst Fastl <er...@gmail.com> wrote:
>
> > Hello everyone,
> >
> > After verifying the patches I send him Catalin was so kind and commited the
> > new sandbox component called PPRPanelGroup to the sandbox.
>
> Hi there!  I think that's the commit I just commented on. :)
>
> Matthias already asked if there was a JIRA issue open, which might
> address my concern about whether we have (or need) a contributor
> license agreement [1] for the new code.
>
> [1] http://www.apache.org/licenses/index.html#clas
>
> --
> Wendy
>


-- 

http://www.irian.at

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

Professional Support for Apache MyFaces

Re: Partial Page Rendering for tomahawk

[Wendy Smoak <ws...@gmail.com>]

On 8/22/06, Ernst Fastl <er...@gmail.com> wrote:

> Hello everyone,
>
> After verifying the patches I send him Catalin was so kind and commited the
> new sandbox component called PPRPanelGroup to the sandbox.

Hi there!  I think that's the commit I just commented on. :)

Matthias already asked if there was a JIRA issue open, which might
address my concern about whether we have (or need) a contributor
license agreement [1] for the new code.

[1] http://www.apache.org/licenses/index.html#clas

-- 
Wendy

Re: Partial Page Rendering for tomahawk

[Matthias Wessendorf <ma...@apache.org>]

> After verifying the patches I send him Catalin was so kind and commited the

which patches?
what is the Jira issue number for that?


> new sandbox component called PPRPanelGroup to the sandbox. With this
> component you can souround areas of a page which you want to be updated
> by AJAX calls. You just specify in the partialTriggers-Attribute a
> comma-seperated
> List of Ids of componenst (e.g. buttons) which trigger this partial update.
>
> This is a initial commit so it is not yet well tested and there are
> still a lot of
> things to do, but if anyone wants to start playing around with it and making
> suggestions for improvements I would be thankful for some feedback.
>
> kind regards
>
> Ernst
>


-- 
Matthias Wessendorf

further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com