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

List:       quanta-devel
Subject:    Re: [quanta-devel] new template ideas
From:       Andras Mantia <amantia () kde ! org>
Date:       2005-12-18 18:15:16
Message-ID: 200512182015.20788.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 18 December 2005 08:11, Jens Herden wrote:
> Let me try to say first what I do not want: I do not want to reinvent
> another CMS, so no database etc. I want all information in text
> files. I do not want to shift the web development on a level where
> the user works only with meta data and Quanta will generate the
> result. I want to keep the binding to the code.

I think it is not about generating, but more about managing the existing 
code and your project. Of course it allows some kind of automated 
build, but the focus would be to help the process of coding,  not to 
code instead of you.

First let's answer some questions from your other mail:

> Where should we store the needed meta information?
Yes, I think they should be inline. And here there should be some error 
recovering mechanism as the user can break such meta information in an 
external editor. In Quanta, once Kate will support, we could use 
readonly sections.

> Some other random questions:
> - do we need to be able to nest objects in objects?
I think it would be good.

> - do we need to have parameters or variables for objects that you
> have to fill before merging? This would be solvable with nested
> objects as well. 
Yes, we should have parameters.

> - do we need a kind of export that creates plain 
> documents without meta-data?

Might be good to have, but I don't see the real reason, except to reduce 
bandwith.

> I see some problems we are not able to solve because they are not
> solveable without additional information. Example: I drop some CSS on
> a document. How should Quanta know where to put it. Simple answer: it
> can never know for sure, there are just to many possibilities. I am
> sure you can imagine hundreds of examples yourself.

We can ask for some more feedback from the user, like:
- include as a link
- put in the header
- select the place in code where to put

> So my proposal is that, as a first step, we just do not care about
> very sophisticated algorithms for solving problems like this. So my
> proposal is based on the principle  that the user has to decide where
> things can get merged, Quanta can only support in merging and
> unmerging. 

Right. But as you wrote in other mails, some templates might have a hint 
where to put CSS objects.

> Let's try to find a common language first.
[...]

> The Quats
> ========
> - are files where Quobs can get merged.
> - know about which Quobs are currently merged in and where.
> - know the order of the merged Quobs. Order is important when you
> nest Quobs. - contain the merged Quobs, there is a copy of the Quob
> inside after merging!
Hm, are you sure about this? Aren't the templates (Quats) only describe 
the place? The actual documents based on the template have the copy of 
Quobs.


> Implementation
> ============
> I think we should create our own namespace and use custom xml tags
> for this. AFAIK do they not interfere in the rendering of HTML. 
I think in HTML unknown tags should simply be ignored. But it is true 
that for some reason such tags are enclosed in comments. It is easier 
to parse if it is not inside comments, though.

[...]
The problem with 
<quanta:quob merge="xpath:/html/head" weight="0">
     <META name="x-test" content="none">
</quanta:quob>

is that it will be inserted in every HTML document, no (there was no 
mergepoint for it)? Do we really want this?

> Now I would like to get use cases. What would you like to do with a
> new template system in Quanta?

An idea is to offer a new, graphical view of the document where you 
could just click and edit parts of it, like:
[source]
[javascript merge, name="the name of the Quob"]
[source]
[header merge, name="the name of the Quob"]
[source]
[footer merge, name="the name of the Quob"]
[source]

One could click on the parts and edit in a document editor (I don't mind 
if the whole document is opened and only the cursor is focused in case 
of [source] parts).
The merge parts should offer different actions, like:
- edit the Quob
- replace with another Quob
- merge permanently
- umerge (remove mergepoint)
- with D&D you could move the mergepoints. In this case if you move over 
a [source] part, it should expand to the source and you could select 
the exact place where to drop.

> I want to know to what extend these ideas can cover the use cases you
> have in mind.

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.

> I also want to know your opinion to these ideas. Where are the
> problems in this design?

I don't know. :-)

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org

[Attachment #5 (application/pgp-signature)]

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