- PROPOSAL: Rearrange Zope Documents
"Christopher G. Petrilli" wrote:
OK, this REALLY shouldn't be difficult, but I've tried every variation of '_' and everythign else I can think of, read the source, seen references to _p_mtime that don't seem to go anywhere... I'm obviously missing something hideously transparent...
How do I insert the time a document was last modified?
i.e. I wanna create standard_html_footer that has something like:
"Last modified: date here"
at the bottom. I can't get anything to resolve correctly.
The problem is that Documents are not what you think they are. They are miss-named. They should be called "DTML Methods". There should be another kind of object called "DTML Documents" that are meant to be the source of information, not a method. They should have properties and search their own attribute namespace before their folder's. Then, when a DTML method, like standard_html_footer, was used in a DTML document, and had: <!--#var bobobase_modification_time--> the modification time of the DTML document would be inserted. I propose, by the end of the Zope beta period to: - Rename Document to "DTML Method", - Add a new object type, "DTML Document", and as a bonus: - Add a new object type, "Structured Text Document", that would use Structured text input and allow DTML tags to be interspursed, possibly using the Python string format or some other less-verbose format than SSI. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
At 12:10 AM 12/9/98 +0000, Jim wrote:
The problem is that Documents are not what you think they are. They are miss-named. They should be called "DTML Methods".
There should be another kind of object called "DTML Documents" that are meant to be the source of information, not a method. They should have properties and search their own attribute namespace before their folder's. Then, when a DTML method, like standard_html_footer, was used in a DTML document, and had:
<!--#var bobobase_modification_time-->
the modification time of the DTML document would be inserted.
I propose, by the end of the Zope beta period to:
- Rename Document to "DTML Method",
- Add a new object type, "DTML Document", and
as a bonus:
- Add a new object type, "Structured Text Document", that would use Structured text input and allow DTML tags to be interspursed, possibly using the Python string format or some other less-verbose format than SSI.
I agree to renaming DTML Methods, but I think a different approach should be taken to Documents. I think we should think more generally in terms of a Content object that can have different encodings like XML, plain text, structured text, XML, HTML, and did I mention XML. That way we don't need a separate type of Object for each separate type of content. As a bonus if Content objects work well, Products like Confera could hold their content in standard Content objects, and so it would be much easier for different types of Products to exchange data. -Amos P.S. I still like to idea I had about making the DTML call stack available. Since I imagine DTML Documents will still want to call DTML Documents, even if DTML methods are available.
Amos Latteier wrote:
I agree to renaming DTML Methods, but I think a different approach should be taken to Documents. I think we should think more generally in terms of a Content object that can have different encodings like XML, plain text, structured text, XML, HTML, and did I mention XML. That way we don't need a separate type of Object for each separate type of content.
What makes Content object different from a DTML document? Is it just a content-type property? I would expect XML objects to have much more structure than, say, plain text or even HTML. For example, I imagine XML objects providing a navigation interface of some kind.
As a bonus if Content objects work well, Products like Confera could hold their content in standard Content objects, and so it would be much easier for different types of Products to exchange data.
But this implies that Content objects have structure. Do you imagine that Content objects have sub-objects? Are they foldoids? Would they provide a mechanism for setting limitations on what kinds of objects could be sub-objects? I think that a driving need that alot of people have expressed is a *simple* mechanism for handling textual content with properties and DTML markup. I'd like to meet that basic need. Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (540) 371-6909 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.
Hi Jim (Jim Fulton), in <366DCD7D.AABA3519@digicool.com> on Dec 09 you wrote:
Amos Latteier wrote:
I agree to renaming DTML Methods, but I think a different approach should be taken to Documents. I think we should think more generally in terms of a Content object that can have different encodings like XML, plain text, structured text, XML, HTML, and did I mention XML. That way we don't need a separate type of Object for each separate type of content.
What makes Content object different from a DTML document? Is it just a content-type property?
Yes, and more. This is what I was talking about wrt things like version control and multi-part documents (handled as one object). Methods to determine not only content-type methods but version (management) methods, sub-object methods, indexing (search) methods (for example), creation, extraction, etc. (As well as containing other things like Conferas.)
I would expect XML objects to have much more structure than, say, plain text or even HTML. For example, I imagine XML objects providing a navigation interface of some kind.
Exactly! navigation interfaces for versions, sub-parts, and for automatically building std view methods, etc.
As a bonus if Content objects work well, Products like Confera could hold their content in standard Content objects, and so it would be much easier for different types of Products to exchange data.
Bingo!
But this implies that Content objects have structure. Do you imagine that Content objects have sub-objects? Are they foldoids?
Yes! Yes!
Would they provide a mechanism for setting limitations on what kinds of objects could be sub-objects?
Yes!
I think that a driving need that alot of people have expressed is a *simple* mechanism for handling textual content with properties and DTML markup. I'd like to meet that basic need.
Great! Thanks! Kent
participants (4)
-
Amos Latteier -
Jim Fulton -
kent＠eaenki.nde.swri.edu -
Phillip J. Eby