cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laurian Gridinoc" <doth...@thedot.net>
Subject KISS
Date Sat, 01 Jan 2000 14:11:40 GMT

Hi to all survivors there :)

I hate the KISS principle - I believe if a thing is complicated enough it
will be simplier... :)

Now the sitemap will ease the maintenance of an site Cocoon-based, but i
want something more complicated, i will try to write what is in my head,
those are raw ideas, please feedback on...

Let's say that i have a site... I see it as an tree of objects, each object
has its XML, XSL and so on, and each object can be mounted through the
sitemap thing.

But, I want more:

A new page -  i will create a new object somewhere in the tree, this new
object will inherit the properties of the parent [style, content, ...], i
would eventually rewrite some of them - like change the style a bit in
couple places,... i'm not sure how this can be done... same the content can
be inherited or it will link back to the parent, and also the content can
include pieces from other objects in the tree

eventually this object it will get an mount point somehow linked to the
parent's, or it will be specified/overwrite by the creator

so, if i change something in the style/content in an object, this change
will be inherited by all the descendants if they don't rewrite it

having things spread on that tree, an object must be viewd from the root,
having its path, we will pass through each node in its path to it, to obtain
it.

ignoring now the sitemap, or consicdering that this tree is the sitemap, an
request to the object will pass through each node to the object building it,
a request could mean more than GET, each node that "is in the way" can
reroute that request according to http headers stuff [user agent,
cookies,...], or it can "stop" the request and handle it if there is no more
rewriting of "what was requested" in the descendant
[i'm thinking at an POST that would eventually be handled in the parent of
the object to who was the POST addressed]

also, the links between objects [i mean hrefs] could be complicated :)
the object A must link to B, in order to do so, the object A request B for
linking, B would return just an URL [mount point in sitemap], or B could
return an piece of html/xml whatever will be the processing ... - this piece
will generate in A the link to B and can contain state information about B

example:
in page A [page being the response of A to GET] there must be a image that
will link to B [B being an chatroom], this link willl have state information
to B: the alt attribute will say: "there is no one in the chatroom right
now"; eventually the href will point to an different URL according with the
fact that the user that accessed A is not registered [B "will see" that who
requested A has no required info in a cookie]

wow,
do i make any sense?

Laurian Gridinoc
Chief Technology Officer
thedot.net, Inc.
www.thedot.net
--
Hell is empty and all the devils are here.
  -- Shakespeare, "The Tempest"


Mime
View raw message