You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lenya.apache.org by Christian Egli <ch...@wyona.com> on 2003/06/16 10:38:53 UTC
Additions to the PageEnvelope
Hi all
I recently added two things to the PageEnvelope
1. document-path
This provides mapping between document-id and file system path of
the document. This enables to define per publication how the
documents are stored. This is used for publishing, rc, editing,
etc.
The idea is to allow for a pluggable architecture where each
publication can configure its own mapping class. Right now there is
one mapper class (DefaultDocumentIdToPathMapper) which defines the
correct mapping for UniCMS and the default publication. At a later
point we can make this configurable to plug in other classes per
publication and we can also provide the mapper classes for the
other typical use-case.
The documentation needs updating for this.
2. user-name and user-fullname
I have a patch in my local workspace which adds the userName and
the userFullName to the PageEnvelope. This works by reading the
user from the session and providing getter classes for the uid and
the full name of this class.
This functionality is at the moment scattered and duplicated in a
lot of xsps, however I don't have time right now to migrate all
this code to the pageenvelope input module. So what I would
suggest, is that I check in my stuff without changing any of the
old code. New classes and xsps will then use the pageenvelope input
module and the "old" code can be migrated later.
What do you think?
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Additions to the PageEnvelope
Posted by Andreas Hartmann <an...@apache.org>.
Gregor J. Rothfuss wrote:
> The document path is related to the page, but I would say the user
> information is not.
> <<
>
> +1 on your concerns to keep stuff seperate. which opens the question
> where to put the user information..
IMHO user information belongs to access control. So it seems that
we need a common access point to obtain access-control related
information.
Maybe we can see the page envelope as a read-only facade for the
publication compartment. The facade pattern has the intent to
"Provide a unified interface to a set of interfaces in a subsystem.
Facade defines higher-level interface that makes the subsystem
easier to use." The page envelope input module is a wrapper for
this facade.
If we agree on this strategy as a best practise, we should think
about creating a similar facade for the access control.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Additions to the PageEnvelope
Posted by Andreas Hartmann <an...@apache.org>.
Christian Egli wrote:
> Well, there was an idea to create an access control input module. I
> could do that.
We have to be cautious about building facades to subsystems
that cover only one client's requirements. This can lead to a
non-natural interface hierarchy, overlapping interfaces and code
duplication.
A facade of a subsystem should encapsulate the functionality
of the subsystem, not provide an access point for a specific
use case.
So I would suggest to use input modules only as coherent wrappers for
general interfaces. Maybe we should not start with with the input
module, rather with a facade.
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: Additions to the PageEnvelope
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
>>
> +1 on your concerns to keep stuff seperate. which opens the question
> where to put the user information..
Well, there was an idea to create an access control input module. I
could do that.
<<
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Additions to the PageEnvelope
Posted by Christian Egli <ch...@wyona.com>.
"Gregor J. Rothfuss" <gr...@apache.org> writes:
>> The document path is related to the page, but I would say the user
>> information is not.
>
> +1 on your concerns to keep stuff seperate. which opens the question
> where to put the user information..
Well, there was an idea to create an access control input module. I
could do that.
--
Christian Egli christian.egli@wyona.com +41 1 272 9161
Wyona AG, Hardstrasse 219, CH-8005 Zurich
Open Source CMS http://www.wyona.org http://www.wyona.com
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
RE: Additions to the PageEnvelope
Posted by "Gregor J. Rothfuss" <gr...@apache.org>.
>>
The document path is related to the page, but I would say the user
information is not.
<<
+1 on your concerns to keep stuff seperate. which opens the question
where to put the user information..
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org
Re: Additions to the PageEnvelope
Posted by Andreas Hartmann <an...@apache.org>.
Christian Egli wrote:
> Hi all
>
> I recently added two things to the PageEnvelope
I'm afraid we have to be aware of the "Swiss Army Knife" Antipattern
here. It is essential that we clearly define the responsibilites
of our objects. Some people say this is the most important aspect
of OO design.
What do we want the page envelope to do? IMHO, "providing all
information needed during the generation of a page" is far too
general, it makes it hard to decide what to put there.
I would constrain it to something like "providing all information
that describes the current page".
The document path is related to the page, but I would say the user
information is not.
What do you think?
Andreas
>
> 1. document-path
>
> This provides mapping between document-id and file system path of
> the document. This enables to define per publication how the
> documents are stored. This is used for publishing, rc, editing,
> etc.
>
> The idea is to allow for a pluggable architecture where each
> publication can configure its own mapping class. Right now there is
> one mapper class (DefaultDocumentIdToPathMapper) which defines the
> correct mapping for UniCMS and the default publication. At a later
> point we can make this configurable to plug in other classes per
> publication and we can also provide the mapper classes for the
> other typical use-case.
>
> The documentation needs updating for this.
>
> 2. user-name and user-fullname
>
> I have a patch in my local workspace which adds the userName and
> the userFullName to the PageEnvelope. This works by reading the
> user from the session and providing getter classes for the uid and
> the full name of this class.
>
> This functionality is at the moment scattered and duplicated in a
> lot of xsps, however I don't have time right now to migrate all
> this code to the pageenvelope input module. So what I would
> suggest, is that I check in my stuff without changing any of the
> old code. New classes and xsps will then use the pageenvelope input
> module and the "old" code can be migrated later.
>
> What do you think?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lenya-dev-unsubscribe@cocoon.apache.org
For additional commands, e-mail: lenya-dev-help@cocoon.apache.org