[prev in list] [next in list] [prev in thread] [next in thread]
List: quanta-devel
Subject: Re: [quanta-devel] a new crash
From: Eric Laffoon <sequitur () easystreet ! com>
Date: 2005-09-14 23:17:52
Message-ID: 200509141617.52595.sequitur () easystreet ! com
[Download RAW message or body]
On Wednesday 14 September 2005 3:15 pm, Paulo Moura Guedes wrote:
> On Wednesday 14 September 2005 22:54, Eric Laffoon wrote:
> > Sure, toss it at me. You were supposed to make it perfect by now. ;-)
>
> Hope we can say that for KDE 4 ;)
>
> Paulo
Yes, in theory we have lots of time and wonderful new developments. In
practice I need you, and possibly Nicolas, to keep your eyes open and
interact with KDOM and KHTML developers to insure we don't find ourselves
closing in on a release with things architecturally not quite what we needed.
I can't stress this enough and I'm thinking about having some chats or phone
conferences as we progress as well as laying out a rough roadmap.
My objective is to get Andras and I together to work on the object templates
and interface for a few weeks the start of next year. This will open up a lot
of possibilities. The main concern with VPL is that I want to achieve what we
talked about, but in a context that might not be obvious.
I'll sum it up in relation to VPL. Visual editing is traditionally focused on
static HTML and therefore less interesting to serious developers. Much of the
preprocessed content is abstracted out and there are difficulties dealing
with this in VPL. The primary benefit of the object template system from your
standpoint is that it will enable files to "know about" each other. A
container file will know what component files are included, but a content
file will know what file(s) contain it and will be able to access document
information from them. Inherently this means that there will be information
available externally for content files, not to mention XSLT on the fly
capabilities. Looking at an example architecture using PHP5 it would be
fairly easy to create a site layout using content files that mark off the
content blocks in XML and then have the container consume the content using
simplexml. Regardless of how a site is architecturally designed it should
still be possible to register an XSL sheet for XML based content or inherit a
container's document information.
One of the features we will get with KDevelop is the ability to modify the
environment which can be tied to roles and tasks in the project. Obviously
finishing our Team Project features and enabling this to work together offers
some serious power for group development. Logically it also means that if we
want to see a large scale adoption it is imperative that we can enable
reliable and powerful content editing in diverse environments with visual
tools. This means a project manager can deliver a simple view of content
files to edit to a content person who in turn would work on them much like
they would a word processor. The rest of the design issues are a matter of
abstraction and site architecture and scripting language and tools would be a
matter of personal choice.
This vision makes visual development useful again to serious developers as
well as making non technical content editing practical for serious teams.
It's a seemingly utopian objective, but it's possible. Other integration
potential is to integrate debug information for PHP to enable simple editing
within loops and such. Another feature we need to include is control of form
variables and the ability to load, test and manipulate for data.
You have to do your part to keep the project leader from looking like he's
talking insane stuff again. ;-)
Eric
_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic