[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]