Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>Tavis Rudd <[EMAIL PROTECTED]> wrote:
>> To be honest this was never high on my list as I never
>> use WYSIWYG tools that muck with your sourcecode. I'm
>> like you and use Emacs for everything.
>> However, many use nothing but WYSIWYG tools and it's
>> a worthy goal to give them something usable.
>
>Another reason this is a good goal: no one seems to do it. I've seen
>*very* few template systems that are friendly to WYSIWYG editors. I
>don't know quite why, except perhaps that, like you, most people
>designing the template language use text editors.
Enhydra's XMLC is designed to be editable in WYSIWYG composition tools. Or so
it is claimed.
>Also, people shouldn't just be able to use WYSIWYG tools, but people
>who use these should be able to interact well with people who don't.
>So, while you *can* use explicit terminators instead of newlines, once
>someone uses newlines the template becomes inaccessible to WYSIWYG
>users.
Things are more likely to work in future if the template syntax remains within
the confines of XML elements and entities. As I noted before, many editors are
not up to the task of dealing with this yet, and probably none are up to
dealing with this in a way that I would like, but XML is certainly the most
natural way of specifying template elements in an XML document.
>[snipsnip]
>> > * Relatively safe to delegate responsibility (kind of
>> > like Zope). For the most part I trust my users not to do
>> > anything too bad, but they will make mistakes. They
>> > should be able to figure out what they've done wrong, and
>> > they shouldn't have any access to Python code. I
>> > consider putting their HTML into a different directory
>> > from code to be sufficient security for the most part.
There's also the form of delegation where you give co-developers the task of
designing the templates, whilst you and others write the logic. Systems with
code in the template (*SP, for example) seem to make this harder.
>> That was one of my original goals, but I shifted away from it
>> upon realizing how complex things can become. The hooks
>> for code security validation are in place so it is possible to
>> build it up if anyone is interested in 'safe-delegation' that
>> guards against malicious stuff.
>
>In a declarative syntax, of course, security is assured by
>definition. I.e., a declarative page doesn't *do* anything, it simply
>is. Of course, it is hard to mix user code and enforce that the page
>is functional in this form. I consider it more of an issue of
>perspective.
Of course, you are going to need useful supporting code to make sure that the
data that the page "reflects" is retrieved and is usable. However, the
separation of such code from the page does potentially provide a means of
reusing both the code and the templates more extensively than would otherwise
be the case.
Regards,
Paul
--
Get your firstname@lastname email for FREE at http://Nameplanet.com/?su
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/webware-discuss
