Jim Washington wrote:
This is probably a bit premature, but I have been doing some thinking
about reordering/batching of large sets.
My current (not-quite-ready-for-prime-time) solution involves
factoradics, and I have done a bit of a write-up on my blog,
http://blog.hill-street.net/?p=5 .
Martijn Faassen wrote:
Jim Washington wrote:
This is probably a bit premature, but I have been doing some thinking
about reordering/batching of large sets.
My current (not-quite-ready-for-prime-time) solution involves
factoradics, and I have done a bit of a write-up on my blog,
Hi Jim. This approach is completely new to me. It is interesting and
I'll keep an eye on your blog. How expensive is updating indexes with
data modification. You are talking about sqlite, does this mean you
figure the indexes would be a significant drag on the ZODB due their
size or is this
David Pratt wrote:
Hi Jim. This approach is completely new to me. It is interesting and
I'll keep an eye on your blog. How expensive is updating indexes with
data modification. You are talking about sqlite, does this mean you
figure the indexes would be a significant drag on the ZODB due their
Hi Stephan. Could a Zope3 branch be set up in the zope repository so
that your enhanced tables code can be added to the branch (so contents
view refactored using it)? The contents view class could be the model
for using the tables package in zope3. In fact, it could be become the
base class
On Tuesday 22 August 2006 09:27, David Pratt wrote:
Hi Stephan. Could a Zope3 branch be set up in the zope repository so
that your enhanced tables code can be added to the branch (so contents
view refactored using it)? The contents view class could be the model
for using the tables package in
Benji York wrote:
Stephan Richter wrote:
Note that I am -1 for including zc.table at this stage. I feel that it
needs some more thought and real-life usage. Note: I use zc.table *a
lot*!
I'm +1 on your -1. It's a bit early yet. Plus the eggification of 3.4
will hopefully reduce the need
Hi. I am wondering if zc.tables could not be incorporated into Zope3
trunk. My rational for its inclusion is so that the contents views may
be refactored to use it. The current contents view makes little sense
without batching and sorting. The ZMI could really use this basic face
lift to bring
On Monday 21 August 2006 15:14, David Pratt wrote:
Hi. I am wondering if zc.tables could not be incorporated into Zope3
trunk. My rational for its inclusion is so that the contents views may
be refactored to use it. The current contents view makes little sense
without batching and sorting. The
On Monday 21 August 2006 17:07, Fred Drake wrote:
Huh? Whatever for? Are you planning to use zc.table for something
other than tabular data? (X)HTML tables are entirely reasonable for
tabular data, which is the only use case I'm aware of.
That depends on the designer you talk to. :-) I
Stephan Richter wrote:
On Monday 21 August 2006 17:07, Fred Drake wrote:
Huh? Whatever for? Are you planning to use zc.table for something
other than tabular data? (X)HTML tables are entirely reasonable for
tabular data, which is the only use case I'm aware of.
That depends on the
On Monday 21 August 2006 17:34, Benji York wrote:
I don't think I'd be very happy with a div-based zc.table.
Then don't use it. It will be an alternative, of course. I will not break the
existing API and output.
Regards,
Stephan
--
Stephan Richter
CBU Physics Chemistry (B.S.) / Tufts Physics
Stephan Richter wrote:
On Monday 21 August 2006 17:34, Benji York wrote:
I don't think I'd be very happy with a div-based zc.table.
Then don't use it. It will be an alternative, of course. I will not break the
existing API and output.
Oh! I misunderstood. I couldn't imagine that the
13 matches
Mail list logo
