seb bacon wrote:
* Joachim Werner [EMAIL PROTECTED] [010618 20:28]:
That's not the behaviour I'd expect. Can anyone confirm this is a
bug?
As LEE Kwan Soo has already said, it is not a bug, but a clever (too
clever?) feature that should maybe not be enabled by default. Every
Michael Bernstein wrote:
But the algorithm doesn't seem 'smart' enough to roll-up the
batches by recursing through them in reverse order. Arguably
though, you should never set your batch size smaller than
the orphan size, so this isn't really an issue.
so maybe the dtml batching code
* Joachim Werner [EMAIL PROTECTED] [010618 20:28]:
That's not the behaviour I'd expect. Can anyone confirm this is a
bug?
As LEE Kwan Soo has already said, it is not a bug, but a clever (too
clever?) feature that should maybe not be enabled by default. Every second
week or so somebody
Hi,
First, I don't post to this list normally; is it the best place to
discuss an apparent bug?
Anyway, the lowdown:
If you iterate over a list with a batch size of 1, it messes up
towards the end of the sequence. For example, the following code:
dtml-call REQUEST.set('hoo',(1,2,3,4))
No it's not a bug(in code) but a feature.
May You call it a bug (in usability), though.
What causes it is that the orphan value defaults to 3 when not explicitely set.
See the online help for in tag.
LEE Kwan Soo
That's not the behaviour I'd expect. Can anyone confirm this is a
bug?
As LEE Kwan Soo has already said, it is not a bug, but a clever (too
clever?) feature that should maybe not be enabled by default. Every second
week or so somebody runs into this and thinks it is a bug.
To the DC people:
Joachim Werner wrote:
That's not the behaviour I'd expect. Can anyone confirm this is a
bug?
As LEE Kwan Soo has already said, it is not a bug, but a clever (too
clever?) feature that should maybe not be enabled by default. Every second
week or so somebody runs into this and thinks it