From quanta-devel Tue Dec 27 10:13:53 2005 From: Eric Laffoon Date: Tue, 27 Dec 2005 10:13:53 +0000 To: quanta-devel Subject: Re: [quanta-devel] new template ideas Message-Id: <200512270213.53753.sequitur () easystreet ! com> X-MARC-Message: https://marc.info/?l=quanta-devel&m=113567833906971 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