'[quanta-devel] new template ideas'

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

List:       quanta-devel
Subject:    [quanta-devel] new template ideas
From:       Jens Herden <jens () kdewebdev ! org>
Date:       2005-12-18 6:11:51
Message-ID: 200512181312.13802.jens () kdewebdev ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

Hi,

I start a new thread here to focus only on this subject. But I refer to the 
other mails about templates here.

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 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. 

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. The logic is in the 
mind of the user and manifests itself in the way how the user designs 
templates. Either the receiving document know where code must get merged or 
the code to merge knows where to go. Anything else is logic and needs code in 
Quanta. 

Let's try to find a common language first. 

Quanta-Object (Quob) = a piece of text with a name and additional attributes 

Quanta-Template (Quat) = a file that has one or more merge points for Quobs

The Quobs
========
- is basicly a piece of text
- have at least one id to define at which merge points they want to merge
- can have merge points for other Quobs. You can nest Quobs.
- have a weight, in case more than one is merged at the same mergepoint. 
Leighter Quobs swim up.
- can have attributes like:
	autoupdate, this would mean when a change in the source 
	of a Quob happens all Quats where the Quob was used gets updated. 

	protect, this would prevent the user from changing the merged Quob in Quanta.

	many more we could invent.

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!

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. For CSS and scripts me 
have to embed this in comments though.

How can we define merge points? There are two ways I can think off: 
1. The user inserts a custom tag. 
2. we use something like XPath to define the tag where the Quob wants to merge

Example
=======

Here a HTML Quat:

<html>
<head>
  <title></title>
  <script language="javascript" type="text/javascript">
  // <!--
  <quanta:mergepoint id="javascript"></quanta:mergepoint>
  // -->
  </script>
</head>
<body>
  <quanta:mergepoint id="header"></quanta:mergepoint>
  <quanta:mergepoint id="footer"></quanta:mergepoint>
</body>
</html>

------------------------------------------------------

Here two Quobs:

This one gets merged where the javascript merge point is. So the definition of 
the merge point is in the Quat.

<quanta:quob merge="javascript" weight="0">
	here some script
</quanta:quob>

This one gets merged in the head tag, the definition of the merge point is the 
the Quob.

<quanta:quob merge="xpath:/html/head" weight="0">
     <META name="x-test" content="none">
</quanta:quob>

---------------------------------------------------------

After the merge:

<quanta:quobhistory>
    <quanta:quobmerge/ id="1" href="url where it came from">
    <quanta:quobmerge/ id="2" href="url where it came from">
</quanta:quobhistory>  
<html>
<head> 
  <quanta:quob merge="xpath:/html/head" weight="0">
     <META name="x-test" content="none">
  </quanta:quob>
  <title></title>
  <script language="javascript" type="text/javascript">
  // <!--
  <quanta:mergepoint id="javascript">
    <quanta:quob id="1" merge="javascript" weight="0">
	here some script
    </quanta:quob>
  </quanta:mergepoint>
  // -->
  </script>
</head>
<body>
  <quanta:mergepoint id="header"></quanta:mergepoint>
  <quanta:mergepoint id="footer"></quanta:mergepoint>
</body>
</html>

------------------------------------------------

Thanks for still reading this :-)

Now I would like to get use cases. What would you like to do with a new 
template system in Quanta? 
I want to know to what extend these ideas can cover the use cases you have in 
mind.
I also want to know your opinion to these ideas. Where are the problems in 
this design? 

Jens

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