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 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 ide
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,
http://blog.h
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 .
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 to
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 .
The idea is that you ca
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 to put things in the c
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
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 wit
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 curr
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 Physic
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 designer
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 ag
On 8/21/06, Stephan Richter <[EMAIL PROTECTED]> wrote:
and make a "div" based alternative.
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.
-Fred
--
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.
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
16 matches
Mail list logo