Daniel Nouri wrote:
I'm sure that
your concepts work nicely for you there. But maybe they are not the most
practical way to define my kind of page composition use case, which needs
to be highly customizable at runtime (vs. zcml time).
Component registrations can be done at runtime easily in
On 23 Jul 2007, at 17:51 , Daniel Nouri wrote:
As to plone.portlets, I think they are heavily overengineered.
Last
time
I looked at its API, it was heavily bloated. This might be a
result of
being a Plone package though, I do not know, but I would certainly
implement them much slimmer.
Hi Stephan!
Stephan Richter wrote:
On Tuesday 17 July 2007 14:28, Daniel Nouri wrote:
plone.portlets introduces some two dozen (!) interfaces/concepts on top of
viewlets in order to implement the flexibility that it needs. E.g. it
introduces an 'available' method/property that controls
Hermann Himmelbauer wrote:
Am Dienstag, 17. Juli 2007 14:08 schrieb Stephan Richter:
On Monday 16 July 2007 19:32, Daniel Nouri wrote:
I do not recommend using views for content that is only
used inside a template. Because context/@@viewname
is also traversable as a real view and will
On Tuesday 17 July 2007 14:18, Daniel Nouri wrote:
Content providers and viewlets are not publically traversable. Being
traversable does not make them insecure but it offers one more point of
access and a potential security hole if not reviewed correctly. Do you
test the security for all
Hi Roger!
Roger Ineichen wrote:
If you like a explicit pattern, then calling views in ZPT is
fine. On the other hand, if you use a viewlet manager,
the manager can implement conditions and show based on
rules e.g. session state or login status more or less
viewlets.
I think best reason to
On Tuesday 17 July 2007 14:28, Daniel Nouri wrote:
plone.portlets introduces some two dozen (!) interfaces/concepts on top of
viewlets in order to implement the flexibility that it needs. E.g. it
introduces an 'available' method/property that controls visibility, which
viewlets by themselves
