Hi, Some thoughts from me regarding the MVC stuff:
1) Routing
I assume you already thought of this, but I would like to see it
mentioned in the document: The routing is one of the most performance
critical parts of the MVC, so that it should be completely replaceable
by the user with an optimized implementation for his usecase.
2) View handling
The selection of views from the controller is not defined yet, and imho
also a key component.
I personally see the common requirements for web applications, which may
be quite a lot, but at least this should be easily possible with user
extensions:
- Context specific templates
The controller returns something to display and it should be possible
to display it in diffenrent output formats (XHTML, Mail, Text,
RDF-XML, ...)
Generally this could be handled by some request object passed to the
viewmanager, which defines the request context. (Locales,
Content-Type, ...)
- "Pagelayout" definition
Even in one context it is often required to get entirely different
outputs, like a popup, a standard and a print view for XHTML. This
could be implemented with more complex context definitions, but you
may want to share some templates between the different HTML views
(perhaps all, except the layout template).
- User overrides of templates
We do this in eZ Publish. We got a set of standard templates, and you
may spcify your custom tempaltes, which override one or two tempaltes
to contain custom formatting. This may be done by checking a list of
user defined directories for a replacement template, or more complex
rules. This is not required by the initial implementation, but still
should be possible.
Possible solutions:
- The standard way to solve this, is a viewmanager, which just takes a
view object from the controller and displays this with a defined
(complex) mapping, based on context and the type of the contents of
the viewObject. The viewObject may of course aggregate lots of other
view objects (like the navigation, ...).
This solution has two drawbacks from my POC:
- It is hard to provide a really simple solution for simple
applications, as this would force all stuff returned by the
controllers to implement at least some interface, which would make
it impossible to just provide some scalar values, etc.
- The overhead by the viewmanager and the defined mapping may be
noticeable, and may result in poor performance. The definition of
the required mapping may look a bit complex to some users...
- Just pass some (pseudo) URL to the viewmanager, like
html/popup/user.tpl, which may be handled by the viewmanager, because
they provide enough context information in the URL, or are just
mapped to the file system, for the simple / dumb solution ;)
This requires extra string parsing in the view manager, which I
generally dislike, though...
Drawbacks:
Both solutions do not directly help with the sharing of the templates
between dfferent contextes, but this could be implemented dooing some
magic in the viewmanager, which may know about the context semantics,
and so also knows which may be shared.
Somebody found the holy grail anywhere?
--
Mit freundlichen Grüßen / Med vennlig hilsen
Kore Nordmann (GPG: 0xDDC70BBB)
eZ Components Developer
eZ systems Headquarters
tel +49 (0) 231-9742-7750 | fax +49 (0) 231-9742-7751
[EMAIL PROTECTED] | eZ systems | ez.no
signature.asc
Description: This is a digitally signed message part
-- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
