Scott,

I need to open up the simple layout discussion again.  I have found the table method limiting when faced with logical style-based layouts.  The latest wall, for instance, is the photo gallery layout of the Property Agent module.  The current method relies on tables but this is a direct violation of the intended use of tables.

Can I help you create stands compliant layouts for the default templates?   I am willing to commit some free time to Ventrian to make the modules xhtml compliant.  I have extensive experience working with CSS, logical layouts and the Ventrian modules.

Sincerely,
Lance

Hi,

Great thread.

My vote is for an unordered list for photos.  Perhaps three tokens would be ideal:-

[MAINPHOTO] Would just generate the 'first' photo - no need for markup as it can be wrapped in a DIV or other element in the template.

[ALLPHOTOS] Would display all photos as

could be defined in the template so that a class or id can be added. Perhaps it could be a token option to created the list with the UL or without.

[CHILDPHOTOS] As for [ALLPHOTOS] but would not include the main photo.

That would fulfill all my requirements :-)

aarrgh

Ooops, try again.

[MAINPHOTO] Would just generate the 'first' photo - no need for markup as it can be wrapped in a DIV or other element in the template.

[ALLPHOTOS] Would display all photos as a list items (wrapped in an LI) with no UL generated so that a class or id can be added. Perhaps it could be a token option to created the list with the UL or without.

[CHILDPHOTOS] As for [ALLPHOTOS] but would not include the main photo.

That would fulfill all my requirements :-)

This PA module use an unordered list to display the photos (the tables are removed by a little jQuery)

We may be talking at cross purposes, but the majority of PA implementations need at least to be able to identify 1 main photo to be treated differently depending on the view (especially summarized views - list views etc).  If you need to take one out, then it's pretty logical extension to say you might want the rest bar that one in some circumstances.

I could toggle off the photo in my CSS - but I'd prefer it not to be sent client in the first place.

The 'optional separation' of 'first' and 'other' photos (you're right there is no hierarchy) matches closely to the current model - less pain for everyone.

I'd agree that xml would have been a good approach, but the current template structure is simple and obvious, easy to tweak and nicely consistent across modules.

I don't share your concerns with breaking structures.  As long as they are easy I'm not too concerned what the templates look like or if they conform to a standard. I just want the template to generate validated html without the current table bloat.

Caroig,

My response regarding the splitting of code came from two things:

1. That you put the UL code in the View Item template. In that case, one would have separated the items between different functions not just different files. This is a dangerous route as they become dependent on each other. For instance, if you wanted to put the gallery in the listing template then it should work and act on its own by supplying the token. It might seem easy to just copy the UL to the new template but it would be error prone and limiting.
2. Your suggestion that the module would output a list LIs. This limits the function to the UL, LI method only which I believe would cause problems down the road. Semantically it makes some sense that the photo are Line Items but if a user want to use Divs for another version of the layout (for instance, an elastic arrangement) then they should be free to do so. 

IHMO

However, I believe we are in agreement that:

• The templates should be made lighter and standard compliant by replacing the tables with CSS layouts. The only barrier to this now is the method used for repeating the images.
• The first image in the gallery should be treated differently so that people can style them specifically.

To be clearer, by 'toggle' I meant the gallery token would not add the first photo - not a CSS method. Once removed (skipped?), the user could apply all the special styles they like using the view item photo tokens. This includes the code to launch Lightbox etc. I also think this is a seperate thread from making the templates standard compliant.

that's what I think:

******** head *******

< ul id="view_photos" >
< li id="first_photo" > some link  < /  li >

******* body *************
< li style=" width:[PHOTOWIDTHMEDIUM] ; height:[PHOTOHEIGHTMEDIUM] ; float:left;"> some other link   <   /   li    >

********* footer ***********

<  /ul >

That is a good start Avi a, there is one problem however - how do you create rows?   There are two ways I see useing ULs ...

< ul>  // row one
 < li>item< /li>
 < li>item< /li>
< /ul>

< ul>  // row two
 < li>item< /li>
 < li>item< /li>
< /ul>

or

< ul>
 < li class="NewRow">item< /li>// row one
 < li>item< /li>
 < li class="NewRow">item< /li> // row two
 < li>item< /li>
< /ul>

The benefit of the second is you can remove the style for NewRow to create elastic/liquid/mobile layouts.  A row becomes a style definition then versus a data definition leaving the presentation up to the client.  Both, however, address how to create the rows.  I think the gallery will require templates for Head, Row, Item and Footer.  There could be a way to have the row and item templates combined if there were the right tokens:

< li  [iSNewRow: class="NewRow"]>item < /li>

All this depends on how Scott wants to change the code. 

It will work graet with that token:
[IMAGE:xx:yy]

So if the defaults for example will be [PHOTOWIDTHMEDIUM] = 160px (height is less important)
and:
[IMAGE:xx:yy] = 140px:140px
then this:
< li style=" width:[PHOTOWIDTHMEDIUM] ; height:[PHOTOHEIGHTMEDIUM] ; float:left;">
should be replaced with this:
< li style=" width:[PHOTOWIDTHMEDIUM] ; height:[PHOTOHEIGHTMEDIUM] ; float:left;padding:10px;">
will creat the padding stuff.

An optional/default [PHOTOSWIZARD] in the photos item.

Basically I think all what I described can be made with 4 questions in the layout settings photos :

use wizard? yes/no

the full frame width: ___px
sidepadding :__px
the full frame height:___px
vertical padding:__px

It will generate the "li" I was describing earlier .
What do you think?

Caroig;  is not the case that the existing PHOTO tokens would work as your MAINPHOTO?  From my experience, I'm able to do many interesting things with these tokens.

Avi a: you are touching on a main criteria - whatever is decided, lower skilled users should be able to control the appearance of the gallery.  This is where the rows and columns come in.  In the current version there is a sett ing "Items Per Row:"  I want to replicate this so the new version is backward compatible.