|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
Just a thought, at the moment sections render like this: Code:
< div class="moduletools">{admin stuff goes in here}< /div>
< div class="section">
{the module content goes in here}
< /div>
The module is inside the section class. Would it be possible to have the section class as the default and also be able to specify the class (from a new setting or something) to be used. Like this: Code:
< div class="moduletools">{admin stuff goes in here}< /div>
< div class="customsectionclassname">
{the module content goes in here}
< /div>
This will make it easier to style without having to wrap things in more divs. Is there already a way to achieve this? I will look at it anyway.
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/3/2006
Posts: 243
Points: 450
Location: the moon :)
|
I looked into this.
1. Often this is called "Chrome" in temr of UI.
For a Section you have some borders, and often you want different borders for different sections.
You really want to be able to specify this at the template level per placeholder, and then all sections in that placeholder get that Chrome.
2. Your question about how the section ID is can easily be changed as you know in the PageEngine, where it does the logic for this.
But to achieve what you are asking about i think the Chrome Method is better, and then the Page Engine can respect what the Chrome aspect tells it to do.
Make sense ?
Ged
if your doing it hard your probably doing it the wrong way....
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/3/2006
Posts: 243
Points: 450
Location: the moon :)
|
I also think this can be done without a DB change.
the Chrome code can be another UserControl, with the name mapping to the placeholders.
Thats all.
The page Engine then parses the template, looks for a chrome named after the placeholder and then does the composition.
This allows people to make it do whatever they want, including what you asked
if your doing it hard your probably doing it the wrong way....
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
gedw99 wrote:I looked into this.
1. Often this is called "Chrome" in temr of UI.
For a Section you have some borders, and often you want different borders for different sections.
You really want to be able to specify this at the template level per placeholder, and then all sections in that placeholder get that Chrome.
This is what I currently do but then I also have an unused div with a class="section". Much better to just be able to set the class if required but also keep it default to class="section" if not otherwise set. You may also put more that one section type in a placeholder in which case (1.) this would not be a good solution. If you could set the class to be used then it would not matter in what placeholder the section is placed. BaseModuleControl.cs: Line 159 Code:
writer.Write("< div class=\"section\">" );
could be something like: Code:
writer.Write("< div class=\""+ this._module.CssClass +"\">" );
or Code:
if(this._module.CssClass != null)
{
writer.Write("< div class=\""+ this._module.CssClass +"\">" );
}
else
{
writer.Write("< div class=\"section\">" );
}
Or maybe from 'this._module.section.CssClass'? This does not ring quite right as yet. Every time I work with Cuyahoga I find things like this and they are quite easy to change. It just takes me a little further away from the trunk. 
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 12/30/2004
Posts: 1,674
Points: 1,824
Location: Wageningen (NL)
|
Personally, I don't see a huge problem when you wrap the section in an extra div to style it differently.
By adding an extra setting as cssclass, you only make things more complex for the end-user, but more importantly, you also create a dependency between the stylesheet and the section that goes into the database. I'm not sure I like that.
|
|
Rank: Administration
Groups: Administration
, Member
Joined: 10/7/2008
Posts: 505
Points: 1,515
|
martijnb wrote:Personally, I don't see a huge problem when you wrap the section in an extra div to style it differently.
By adding an extra setting as cssclass, you only make things more complex for the end-user, but more importantly, you also create a dependency between the stylesheet and the section that goes into the database. I'm not sure I like that. I agree that it is not a huge problem. Although when you have three sections added to a single placeholder then styling them becomes more of a pain than it could be. Having some way of specifying a css class (that still defaults to 'section' if no value set) would work. Code:< div class="customsectoncss">
{content}
< /div> I currently build the module markup like this. Code:< div class="secton">
< div class="modulespecificcss">
{content}
< /div>
< /div> I will use a module setting (custom settings in admin) that asks for an optional css class string (defaults to 'section'  . This will allow different css class for each section rather than module. So no need to start messing around with Cuyahoga itself for such a little thing. One way or another there is a way to do what I am looking for without any changes. I just needed to take a step back a little.
|
|
Rank: Advanced Member
Groups: Member
Joined: 4/3/2006
Posts: 243
Points: 450
Location: the moon :)
|
Constructor,
The ability to specify a css class for a sections is a easy route architecturally i agree.
It break the Idea of the Templates and Module being complexity separate in terms of UI styling however.
Martin also mentioned that he does not want to introduce a dependency between the Templates and Modules.
The Chrome way is nice because the dependency is contained FULLY at the template level.
This is only for the borders of sections, and does nothing to the html inside a section.
The CHrome way It also allows the Admin UI that appears above sections to be also customized easily at the template level only.
The Page engine class is now fully independent of the UI. All that has to happen is that the Chrome class for a template respects a simple interface, so that the Page engine can inject the links it needs to.
I knwo this is not exactly what you guys are talking about but i thinks its a worthwhile approach because it kills many issues and makes the platform of Cuyahoga much more extensible.
ged
if your doing it hard your probably doing it the wrong way....
|
|
|
Guest |