[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta-devel
Subject:    Re: [quanta-devel] new template ideas
From:       Eric Laffoon <sequitur () easystreet ! com>
Date:       2005-12-27 10:13:53
Message-ID: 200512270213.53753.sequitur () easystreet ! com
[Download RAW message or body]

On Monday 19 December 2005 5:08 pm, Jens Herden wrote:
> > I would also like more from Eric, based on this. I want to base our
> > discussion on your ideas, so we have something concrete that we can
> > modify, extend, discuss, instead of talking in general terms about
> > ideas.
>
> Agreed, but if possible I would like to think now not about the
> implementation details but about what use cases we have, what we want to
> cover with such a system.
>
> Jens

This is a very intersting idea. I want to ponder it and discuss it some more, 
but it's fundamentally different from what I was proposing. That doesn't take 
away from it's merit or interest, though it might be somewhat confusing to 
introduce a lot of stuff at once. What is interesting is the on-the-fly 
nature of this and the ability to set up merging of elements.

Let me reiterate my thinking with templates, which is fundamentally different. 
I'd be open to both and open to ideas integrating into mine too. I'll try to 
relate it to Jens' perspective here to see if it makes more sense to him.

1) Container template - The idea is to have a master "parent" template which 
can accept child templates. So in order to use "object templates" you must 
first have a parent object. It should be easy to take an existing file and 
import it as an object template. This would manage interactions. Note that 
initially I did not conceive that any template dropped onto it would go to 
any location other than where it was dropped, but my idea was that in 
managing relationships it would be aware of where things were in the head of 
the document and such.

2) Child template - When dropping a template on a container it would 
communicate it's requirements to the container along with it's drop request. 
This opens a lot of doors for things that could be done. For instance in a 
very advanced application it could even disallow a drop of templates that 
didn't meet certain requirements and thow an error dialog.

3) Mediation engine - The container template would communicate with rules, 
instructions and requirements with the mediation engine. The actual hard 
coding should be minimal, simply allowing definitions and instructions to 
interact with attributes. In this way a flexible system could be populated 
with basic HTML and CSS management tools, but it could also be used for other 
things like XML databases or PHP and Javascript library management.

3) Template attributes - Containers and child templates would carry their data 
here. A Kommander interface would be generated to manage attributes as they 
are defined by the user for their object system.

First of all this is probably more complex than what would be carried inside 
templates, but it could be. Alternately dot files could be used. This could 
be written in XML or some other readable format that could be accessed by 
other programs.

Now, to distinguish between what Jens proposed and what I proposed. Jens' idea 
is interesting for it's purpose, and may have useful aspects for inclusion in 
my idea. His point about simplicity and not adding anything is valid if your 
objective is a basic and simple tool enhancement. My idea is really a radical 
design departure. It is to be able to use design elements you have now, 
assuming good object oriented design is being used, and gradually transform 
from repetitive work to automating your design decisions. As such I feel it 
warrants a more radical approach. As to whether you can use it in other 
editors... I would only agree to that if it was not imposing a severe 
limitation on what we were trying to do. In this case I think it's up to 
other editors to copy us. This is meant to be a radical departure.

Combined with the above is the ability to group elements. So you could look at 
all containers from a particular root or all containers which use a given CSS 
structure or layout. Clearly this is still open to discuss particular 
details, but the objective in my mind is clear... when you work on a document 
in a word processor you can look at and modify the whole thing. When you work 
on a web site you can only work on one little thing at a time. This is 
because nobody has defined an interface paradigm that works to look at the 
site as a whole and I find that to be a serious deficiency. We need to get 
away from looking at this as an HTML issue like they did with Dreamweaver. We 
got away from looking at just HTML with DTEPs and now we can bring the 
benefits to XML or PHP. Likewise this design concept needs to be just as 
flexible. I have no intention of starting to copy others now. ;-)

Getting back to where something goes on a page, initially I was thinking of 
marking it for where a class would go, such as header, content, script, 
form... Of course this gets more complicated where more than one instance 
could be there. Possibly a syntax for instances would work. It would be 
possible if we drop a child object on a view for it to ask for clarification 
as to the drop point. All of this would be handled by the mediation engine 
and the rules defined for the container and child. As the user works with the 
objects they can open an object attribute dialog and refine it's behavior.

To sum up what I said before, this should be something that can be gradually 
incorporated with existing code and the user should be able to use it as a 
loose framework and optionally develop a very tight environment to handle 
most of the development tasks. Obviously it's easy for them to adopt as a 
framework and very involved to use as the primary design interface, but it 
should transition at their discretion. 

The payoff for the tools that manage these concepts is the ability to extend 
any development model, create cleaner more consistent design work more 
quickly, see the project based on conceptual linkage and most importantly 
reduce development overhead substantially over several months use. I think 
that's worth the trade offs. 

Now to address the aspect of using another editor to develop with... Given 
that our templates are just part of the file system it would still be 
possible to copy and paste snippets into files with any editor. Provided 
these carry identification the only limitation would be how they interacted 
at that time. It would be possible to open the project in Quanta and instruct 
it to rerun the addition of all templates to a given file or tree and have it 
re-process. Even more interesting is that I'd really like to use scripting as 
much as possible for the actual instructions... So it would be possible to 
add a template with another editor and then manually tell a script to run.

At the moment it's 2 am and I'm still recovering from the mad holiday rush, 
but I know there are some really brilliant people on this list when it comes 
to fleshing out details. I can do details better when I'm not so tired. I 
know though that if Andras and Jens and I argue enough that we're all 
moderately happy with the outcome it will be awe inspiring to everyone who 
sees it. ;-)

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]