From quanta-devel Wed Sep 14 23:17:52 2005 From: Eric Laffoon Date: Wed, 14 Sep 2005 23:17:52 +0000 To: quanta-devel Subject: Re: [quanta-devel] a new crash Message-Id: <200509141617.52595.sequitur () easystreet ! com> X-MARC-Message: https://marc.info/?l=quanta-devel&m=112673990617208 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