> Introduction : I notice the "content" area on the
> page properties form. I
> also notice that the current technique to put
> articles is to sort of
> "include" them in a table cell after the "content"
> tag has been put in the
> cell through his page element container..
That's a correct obervation I think, but you do not
necessarily have to walk the beaten track. I myself
am using a "root" style ("root" style is not
necessarily the style of the root page, it means a
style with the elements that are common to all pages
in the site) over the entire website, with different
substyles for parts of the site (I try to keep code
that has to do with layout in a style, so sometimes I
define a substyle to be applied to one page only).
In the "root" style, I do not use the element
<[content]>: instead I use a custom style element
<[display_content]>, however, the definition of
<[display_content]> in the root style contains simply
<[content]>. The advantage however of not using
<[content]> directly is that I can override
<[display_content]> in the substyles, in order to
embed the <[content]> element with some other code, or
even omit it altogether. (and instead put for example
some code in the <[display_content]> that, based on
the URI or the page name, fetches some articles out of
the content tree starting on a dynamically defined
parent topic node).
> Question : What if you want two different cells
> filled by two different
> articles given the fact that "content" is unique to
> each page. If I put the
> "content" tag in one cell and another "content" tag
> in the other cell, it
> will repeat twice the same article. The only
> solution I see would be to
> give to the "content" coding the task of
> "formatting" each cell AND that of
> "including" the articles? Is this the correct way
> to go?
You _can_ do this, but then you are in fact putting
non page-specific code in a page specific element:
indeed you probably want those two cells on all, or
almost all of the pages on your site, which has as a
consequence you'll have to repeat the double cell
formatting in (almost) all of the content fields of
your pages: that's not the separation of logic and
content we're aiming for. Even when you take the
logical step of defining extra style elements in your
root style and and using them in the content of your
page ...
<[style_element_with_html_begin_two_cells]>
code_to_fill_first_element_with_articles
<[style_element_with_cell_connecting_html]>
code_to_fill_second_element_with_articles
<[style_element_with_html_end_two_cells]>
.... you nicely isolate the cell formatting code into
one-time defined style elements, but still they rely
on the page-specific content code to be displayed...
Another solution would be putting the cell formatting
code in the style, and use some checking variable
trick to differentiate between the left and right cell
content (meaning you set a variable
$left_or_right_content in the style to a specific
value to make the <[content]> element display the left
cell content on one occurrence, reassign the variable
to display the right cell content on a second
occurrence of the <[content]> tag. The disadvantage
here is off course that you have to test
$left_or_right_content in the <[content]> code, hereby
again creating a "coupling" between page-specific code
and style code. More or less analogous option: define
different couples of php functions
(display_left_cell() and display_right_cell) in the
content field for every page with the two-cell layout,
and call these functions in your style after including
the <[content]> tag.
In order to reduce the coupling, I'd use the content
page field for one "content cell" only, and put the
code for the other cell in an extra page element.
This way you have a style containing all the layout
code and containing two page-specific elements
<[content]> and <[second_content_cell]>, but you'll
have to define this <[second_content_cell]> page
element for every page explicity (onless you make can
make it inheritable off course). But since you had to
write page-specific code in the <[content]> field
anyway, I think this is a more elegant solution.
Regards,
pascal
__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions!
http://auctions.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
