Howard,
you know better then me that there are other ways to cache resources ;-p
On 10/14/07, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>
> Because it is perfectly shared and uniform, reasonable to cache (portions
> in
> memory), uniformly accessible from multiple machines, etc.
>
> However, su
Yes, I have worked with a system like this, though not as complete as what
you describe.
I wasn't intimately acquainted with it but what seemed to have been
implemented was a repository for the attributes that should be used when,
for instance, controlling rendering. What was interesting was that t
Because it is perfectly shared and uniform, reasonable to cache (portions in
memory), uniformly accessible from multiple machines, etc.
However, such systems rarely get other aspects right, like coordinating code
changes with content changes, or providing adequate history (equivalent to
Subversion
I always wonder why some ppl want to use a db like a file system.
On 10/13/07, Renat Zubairov <[EMAIL PROTECTED]> wrote:
>
> I've worked once with the application where all content, e.g. HTML,
> Javascript, CSS was put in the DB. Not very good idea .
>
> Renat
>
> On 12/10/2007, Daniel Jue <[EMAIL
I've worked once with the application where all content, e.g. HTML,
Javascript, CSS was put in the DB. Not very good idea .
Renat
On 12/10/2007, Daniel Jue <[EMAIL PROTECTED]> wrote:
> Hi all, this is not Tapestry related, but since people here keep up
> with the cutting edge frameworks, I'm wond
Hi all, this is not Tapestry related, but since people here keep up
with the cutting edge frameworks, I'm wondering if you've ever heard
of something like this:
I've been invited to work on an internal company application (that we
resell) that is totally database driven. As in, the _entire_ web
a
