I've also opened an issue where we can track deprecation changes (I
updated the web site file for AutoUpdateDataTable.)
TOMAHAWK-948
Deprecate AutoUpdateDataTable; Replace with pprPeriodicalUpdate
On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Sounds great! I've closed the open
great!
On 3/30/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
I've also opened an issue where we can track deprecation changes (I
updated the web site file for AutoUpdateDataTable.)
TOMAHAWK-948
Deprecate AutoUpdateDataTable; Replace with pprPeriodicalUpdate
On 3/29/07, Mike Kienenberger
+1 on fully removing it.
Anyone not willing to migrate can stick with an older sandbox.
Martin Marinschek wrote:
Hi *,
there is one more reason, why the component should be removed - it is
using prototype under the covers, and we moved to dojo a while ago.
regards,
Martin
On 3/29/07,
Well, the same outcome can be performed by using ppr in combination
with the automatically refreshing mechanism.
This is the more generic way, so a special component which achieves
the same should be
dropped.
The only thing is, that some user may use AutoUpdateDataTable, but
these are
I mean, it's sandbox and since there was a reason for setting it to deprecated,
it seems reasonable to remove; sandbox I'd not consider as a stable API...
At least we should remove the demo...
-M
On 3/29/07, Gerald Müllan [EMAIL PROTECTED] wrote:
Well, the same outcome can be performed by
Ok, let`s remove the demo and leave the component as deprecated.
On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
I mean, it's sandbox and since there was a reason for setting it to deprecated,
it seems reasonable to remove; sandbox I'd not consider as a stable API...
At least we
I am with Mathias that we should remove completely those components in
the API that fail and are not maintained. I see no need to keep them
in the API if they are not supported now already. Maybe we could
define the set of conditions to remove a component from the sandbox
(we already have the
Yeah,
deprecated is a nice condition ...
It is more a pain to have an unmaintained component in a *sandbox*
than simple remove it.
On 3/29/07, Bruno Aranda [EMAIL PROTECTED] wrote:
I am with Mathias that we should remove completely those components in
the API that fail and are not
If I don't hear comments against it,
I'll do it in some days (to give feedback a chance ;-))
-M
On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Yeah,
deprecated is a nice condition ...
It is more a pain to have an unmaintained component in a *sandbox*
than simple remove it.
On
and good to me..
regards,
Martin
On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Sounds good to me.
On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
If I don't hear comments against it,
I'll do it in some days (to give feedback a chance ;-))
-M
On 3/29/07, Matthias
Actually, I'm not so sure now. It looks like we have at least one
person submitting patches for this component. Should it really be
deprecated? Is there an equivalent replacement? If not, and someone
is providing patches, I think we should consider keeping it.
Ok, but the demo says use pprPeriodicalUpdate
http://example.irian.at/example-sandbox-20070329/pprPanelGroupPeriodicalUpdate.jsf
So, when that is maintained by a committer and the other not, we
shoudl get rid of it
-M
On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Actually, I'm not
That's what I was asking -- is there an equivalent replacement?
Maybe pprPeriodicalUpdate? I haven't used either, so I wouldn't
know.
On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Ok, but the demo says use pprPeriodicalUpdate
Why not wait PPR promotion to delete it?
Glauco P. Gomes
Mike Kienenberger escreveu:
That's what I was asking -- is there an equivalent replacement?
Maybe pprPeriodicalUpdate? I haven't used either, so I wouldn't
know.
On 3/29/07, Matthias Wessendorf [EMAIL PROTECTED] wrote:
Ok, but the
The periodicalUpdate mechanism of ppr-group goes beyond
AutoUpdateDataTable, means
it fulfills all its requirements and does little bit more (like
updating not only the table, but the whole area inside the ppr-goup).
I will furthermore support this addition to ppr.
Well, waiting for
Sounds great! I've closed the open AutoUpdateDataTable issues to
either encourage migration (or encourage participation in this
discussion).
On 3/29/07, Gerald Müllan [EMAIL PROTECTED] wrote:
The periodicalUpdate mechanism of ppr-group goes beyond
AutoUpdateDataTable, means
it fulfills all
And if you move the autoUpdateDataTable to jsf-comp in Source Forge?
Glauco P. Gomes
Gerald Müllan escreveu:
The periodicalUpdate mechanism of ppr-group goes beyond
AutoUpdateDataTable, means
it fulfills all its requirements and does little bit more (like
updating not only the table, but the
Hi *,
there is one more reason, why the component should be removed - it is
using prototype under the covers, and we moved to dojo a while ago.
regards,
Martin
On 3/29/07, Glauco Pimentel Gomes [EMAIL PROTECTED] wrote:
And if you move the autoUpdateDataTable to jsf-comp in Source Forge?
nice,
thx
-M
On 3/29/07, Mike Kienenberger [EMAIL PROTECTED] wrote:
Sounds great! I've closed the open AutoUpdateDataTable issues to
either encourage migration (or encourage participation in this
discussion).
On 3/29/07, Gerald Müllan [EMAIL PROTECTED] wrote:
The periodicalUpdate mechanism
19 matches
Mail list logo
