Layout handling
19 views
Skip to first unread message
Daniel Lohse
Nov 30, 2009, 10:14:26 AM11/30/09
to diem-...@googlegroups.com
Hello all,
I have another question. I have a not-so-complex layout file that's quite short and has a few divs inside with IDs and classes.
It's a simple site so site content from Diem is only going to be injected into one specific div. So in symfony I just did an "echo $sf_content" inside that div and I'm ready.
So, I discovered that there are automatically created header and footer partials that only need to be dropped into a zone.
My question is mainly: can I define zones via PHP? Because as it is now the layout seems to live right in the database and the structure is not what I need it to be.
Here's the whole thing in a Pastie: http://pastie.org/720272
Cheers, Daniel
I have another question. I have a not-so-complex layout file that's quite short and has a few divs inside with IDs and classes.
It's a simple site so site content from Diem is only going to be injected into one specific div. So in symfony I just did an "echo $sf_content" inside that div and I'm ready.
So, I discovered that there are automatically created header and footer partials that only need to be dropped into a zone.
My question is mainly: can I define zones via PHP? Because as it is now the layout seems to live right in the database and the structure is not what I need it to be.
Here's the whole thing in a Pastie: http://pastie.org/720272
Cheers, Daniel
thibault
Nov 30, 2009, 10:23:55 AM11/30/09
to diem-...@googlegroups.com
I really need to write a doc about this. I'm afraid I'll have no time
for that today nor tomorrow cause I'll be away.
Diem handles all layout management, and you shoud not do it this way (
but it's not documented yet so you can't guess it ).
<html>, <head> and <body> tags are managed by the layout_helper
service. It takes care of specifying page culture, add seo metas,
include assets and all that kind of things we don't want to worry
about. You may replace the slayout_helper service class in your
apps/front/config/dm/services.yml if you want to change the way it
proceeds, but I think this is not what you need.
To change the way header, footer and other parts are displayed, copy and paste
dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
to
apps/front/modules/dmFront/templates/pageSuccess.php
Here you can manage all pages contents.
2009/11/30 Daniel Lohse <annism...@googlemail.com>:
for that today nor tomorrow cause I'll be away.
Diem handles all layout management, and you shoud not do it this way (
but it's not documented yet so you can't guess it ).
<html>, <head> and <body> tags are managed by the layout_helper
service. It takes care of specifying page culture, add seo metas,
include assets and all that kind of things we don't want to worry
about. You may replace the slayout_helper service class in your
apps/front/config/dm/services.yml if you want to change the way it
proceeds, but I think this is not what you need.
To change the way header, footer and other parts are displayed, copy and paste
dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
to
apps/front/modules/dmFront/templates/pageSuccess.php
Here you can manage all pages contents.
2009/11/30 Daniel Lohse <annism...@googlemail.com>:
Alfonso Alba García
Nov 30, 2009, 10:47:00 AM11/30/09
to diem-users
Hi thibault:
First of all, thanks por making diem open source. It's really
promising and I'm giving it a shot in my next (small) project.
I have a question related to this one. By default, you define in diem
4 "areas" top,left,content.right, bottom. Let's say my pages hav two
lay outs:
that my layout is much simpler than this: I only have top,
content,bottom. What is the proper way to implement this? What I
expect is to see only this zones in the admin area for the pages
On 30 nov, 16:23, thibault <thibault.duples...@gmail.com> wrote:
> I really need to write a doc about this. I'm afraid I'll have no time
> for that today nor tomorrow cause I'll be away.
>
> Diem handles all layout management, and you shoud not do it this way (
> but it's not documented yet so you can't guess it ).
>
> <html>, <head> and <body> tags are managed by the layout_helper
> service. It takes care of specifying page culture, add seo metas,
> include assets and all that kind of things we don't want to worry
> about. You may replace the slayout_helper service class in your
> apps/front/config/dm/services.yml if you want to change the way it
> proceeds, but I think this is not what you need.
>
> To change the way header, footer and other parts are displayed, copy and paste
> dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
> to
> apps/front/modules/dmFront/templates/pageSuccess.php
>
> Here you can manage all pages contents.
>
> 2009/11/30 Daniel Lohse <annismcken...@googlemail.com>:
First of all, thanks por making diem open source. It's really
promising and I'm giving it a shot in my next (small) project.
I have a question related to this one. By default, you define in diem
4 "areas" top,left,content.right, bottom. Let's say my pages hav two
lay outs:
that my layout is much simpler than this: I only have top,
content,bottom. What is the proper way to implement this? What I
expect is to see only this zones in the admin area for the pages
On 30 nov, 16:23, thibault <thibault.duples...@gmail.com> wrote:
> I really need to write a doc about this. I'm afraid I'll have no time
> for that today nor tomorrow cause I'll be away.
>
> Diem handles all layout management, and you shoud not do it this way (
> but it's not documented yet so you can't guess it ).
>
> <html>, <head> and <body> tags are managed by the layout_helper
> service. It takes care of specifying page culture, add seo metas,
> include assets and all that kind of things we don't want to worry
> about. You may replace the slayout_helper service class in your
> apps/front/config/dm/services.yml if you want to change the way it
> proceeds, but I think this is not what you need.
>
> To change the way header, footer and other parts are displayed, copy and paste
> dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
> to
> apps/front/modules/dmFront/templates/pageSuccess.php
>
> Here you can manage all pages contents.
>
Daniel Lohse
Nov 30, 2009, 10:51:42 AM11/30/09
to diem-...@googlegroups.com
Thanks for this information! :) I'm in the middle of implementing aforementioned layout.
What I'd like to know is this:
1. Do there have to be any IDs/classes in the source code for the JavaScript to work?
2. What is renderAccessLinks() function doing? I can't find it. ;-)
Thanks for all the hard work you put into this!
Daniel
What I'd like to know is this:
1. Do there have to be any IDs/classes in the source code for the JavaScript to work?
2. What is renderAccessLinks() function doing? I can't find it. ;-)
Thanks for all the hard work you put into this!
Daniel
thibault
Nov 30, 2009, 10:51:50 AM11/30/09
to diem-...@googlegroups.com
Well, if you don't need left nor left layout columns, just hide them with CSS :
.dm_layout_left,
.dm_layout_right {
width: 0px;
}
.dm_layout_center {
width: 100%;
}
If you also don't want them not to appear in HTML code, copy and paste
dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
to
apps/front/modules/dmFront/templates/pageSuccess.php
and then comment the lines where left and right are displayed :
<?php
echo £o('div#dm_page'.($sf_user->getIsEditMode() ? '.edit' : ''));
echo $helper->renderAccessLinks();
echo £('div.dm_layout',
$helper->renderArea('top', '.clearfix').
£('div.dm_layout_center.clearfix',
// $helper->renderArea('left').
$helper->renderArea('content').
// $helper->renderArea('right')
).
$helper->renderArea('bottom', '.clearfix')
);
echo £c('div');
2009/11/30 Alfonso Alba García <aalba...@gmail.com>:
.dm_layout_left,
.dm_layout_right {
width: 0px;
}
.dm_layout_center {
width: 100%;
}
If you also don't want them not to appear in HTML code, copy and paste
dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
to
apps/front/modules/dmFront/templates/pageSuccess.php
and then comment the lines where left and right are displayed :
<?php
echo £o('div#dm_page'.($sf_user->getIsEditMode() ? '.edit' : ''));
echo $helper->renderAccessLinks();
echo £('div.dm_layout',
$helper->renderArea('top', '.clearfix').
£('div.dm_layout_center.clearfix',
// $helper->renderArea('left').
$helper->renderArea('content').
// $helper->renderArea('right')
).
$helper->renderArea('bottom', '.clearfix')
);
echo £c('div');
2009/11/30 Alfonso Alba García <aalba...@gmail.com>:
Alfonso Alba García
Nov 30, 2009, 10:57:18 AM11/30/09
to diem-users
Sorry, the mouse pad of the laptop decided to send the message before
I finished :-). I start over:
I have a question related to this one. By default, you define in diem
5 "areas" top,left,content.right, bottom. Let's say my pages have two
layouts:
1. complex 5 areas defalut layout
2. a simple layout in which I only have top, content,bottom.
What is the proper way to implement this? What I expect is:
1. if I edit a page with the full layout, I expect to see all the
areas.
2. If I edit a page with the simple layout, I expect to see only the
three areas.
What i did is I duplicated the default template and deleted the left
and right zones. Is this the proper way to do it? I have the feeling
there must be a better way. and finally, what happens if I need a four
column layout? how do I add a the new Area?
Thanks,
Alfonso.
I finished :-). I start over:
I have a question related to this one. By default, you define in diem
layouts:
1. complex 5 areas defalut layout
2. a simple layout in which I only have top, content,bottom.
What is the proper way to implement this? What I expect is:
1. if I edit a page with the full layout, I expect to see all the
areas.
2. If I edit a page with the simple layout, I expect to see only the
three areas.
What i did is I duplicated the default template and deleted the left
and right zones. Is this the proper way to do it? I have the feeling
there must be a better way. and finally, what happens if I need a four
column layout? how do I add a the new Area?
Thanks,
Alfonso.
thibault
Nov 30, 2009, 11:02:19 AM11/30/09
to diem-...@googlegroups.com
1. Yes, front edition tools require classes like dm_zone, dm_widget
and some more. Do you need the list ?
2. It renders a hidden link to your site content for accessibility purpose.
2009/11/30 Daniel Lohse <annism...@googlemail.com>:
and some more. Do you need the list ?
2. It renders a hidden link to your site content for accessibility purpose.
2009/11/30 Daniel Lohse <annism...@googlemail.com>:
Alfonso Alba García
Nov 30, 2009, 11:05:39 AM11/30/09
to diem-users
My question was incomplete, touched the mousepad and I sent it before
I finished. Anyway, thanks for the answer.
Now, the second part of the question was: How do you implement for
example a four column layout? How do I add a new area to the page?
Alfonso
I finished. Anyway, thanks for the answer.
Now, the second part of the question was: How do you implement for
example a four column layout? How do I add a new area to the page?
Alfonso
Daniel Lohse
Nov 30, 2009, 11:11:00 AM11/30/09
to diem-...@googlegroups.com
I understand that editing directly in the web site requires these classes but the weird thing is that in the prod environment all of the zone/widget classes and wrapping code is still rendered.
I thought the areas/zones were only rendered fully when a admin user (translator, webmaster etc.) accessed the site from the dev environment, and only in this combination.
In all other cases only the content of the areas is rendered and no diem front editing code.
Can you understand what I'm saying?
Daniel
I thought the areas/zones were only rendered fully when a admin user (translator, webmaster etc.) accessed the site from the dev environment, and only in this combination.
In all other cases only the content of the areas is rendered and no diem front editing code.
Can you understand what I'm saying?
Daniel
Daniel Lohse
Nov 30, 2009, 11:11:44 AM11/30/09
to diem-...@googlegroups.com
Just look at the pageSuccess.php from Diem (like he described). Their you'll see how.
Daniel
Daniel
ornicar
Dec 1, 2009, 8:21:53 AM12/1/09
to diem-users
"I thought the areas/zones were only rendered fully when a admin user
(translator, webmaster etc.) accessed the site from the dev
environment, and only in this combination.
In all other cases only the content of the areas is rendered and no
diem front editing code."
I totally understand. I tried to do so one year ago. But there's a
(translator, webmaster etc.) accessed the site from the dev
environment, and only in this combination.
In all other cases only the content of the areas is rendered and no
diem front editing code."
problem.
When the template/CSS writer creates the site, he is always logged,
and so the html code contains diem tags and classes. So he can rely on
them for writing CSS.
If some tags and classes disappear when he logs out, it could break
the site style.
On Nov 30, 5:11 pm, Daniel Lohse <annismcken...@googlemail.com> wrote:
> I understand that editing directly in the web site requires these classes but the weird thing is that in the prod environment all of the zone/widget classes and wrapping code is still rendered.
> I thought the areas/zones were only rendered fully when a admin user (translator, webmaster etc.) accessed the site from the dev environment, and only in this combination.
>
> In all other cases only the content of the areas is rendered and no diem front editing code.
>
> Can you understand what I'm saying?
>
> Daniel
>
> On 2009-11-30, at 30/November, 5:02 PM, thibault wrote:
>
> > 1. Yes, front edition tools require classes like dm_zone, dm_widget
> > and some more. Do you need the list ?
>
> > 2. It renders a hidden link to your site content for accessibility purpose.
>
> >> Thanks for this information! :) I'm in the middle of implementing aforementioned layout.
>
> >> What I'd like to know is this:
> >> 1. Do there have to be any IDs/classes in the source code for the JavaScript to work?
> >> 2. What is renderAccessLinks() function doing? I can't find it. ;-)
>
> >> Thanks for all the hard work you put into this!
>
> >> Daniel
>
> >> On 2009-11-30, at 30/November, 4:23 PM, thibault wrote:
>
> >>> I really need to write a doc about this. I'm afraid I'll have no time
> >>> for that today nor tomorrow cause I'll be away.
>
> >>> Diem handles all layout management, and you shoud not do it this way (
> >>> but it's not documented yet so you can't guess it ).
>
> >>> <html>, <head> and <body> tags are managed by the layout_helper
> >>> service. It takes care of specifying page culture, add seo metas,
> >>> include assets and all that kind of things we don't want to worry
> >>> about. You may replace the slayout_helper service class in your
> >>> apps/front/config/dm/services.yml if you want to change the way it
> >>> proceeds, but I think this is not what you need.
>
> >>> To change the way header, footer and other parts are displayed, copy and paste
> >>> dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
> >>> to
> >>> apps/front/modules/dmFront/templates/pageSuccess.php
>
> >>> Here you can manage all pages contents.
>
> >>> 2009/11/30 Daniel Lohse <annismcken...@googlemail.com>:
>
> >> What I'd like to know is this:
> >> 1. Do there have to be any IDs/classes in the source code for the JavaScript to work?
> >> 2. What is renderAccessLinks() function doing? I can't find it. ;-)
>
> >> Thanks for all the hard work you put into this!
>
> >> Daniel
>
> >> On 2009-11-30, at 30/November, 4:23 PM, thibault wrote:
>
> >>> I really need to write a doc about this. I'm afraid I'll have no time
> >>> for that today nor tomorrow cause I'll be away.
>
> >>> Diem handles all layout management, and you shoud not do it this way (
> >>> but it's not documented yet so you can't guess it ).
>
> >>> <html>, <head> and <body> tags are managed by the layout_helper
> >>> service. It takes care of specifying page culture, add seo metas,
> >>> include assets and all that kind of things we don't want to worry
> >>> about. You may replace the slayout_helper service class in your
> >>> apps/front/config/dm/services.yml if you want to change the way it
> >>> proceeds, but I think this is not what you need.
>
> >>> To change the way header, footer and other parts are displayed, copy and paste
> >>> dmFrontPlugin/modules/dmFront/templates/pageSuccess.php
> >>> to
> >>> apps/front/modules/dmFront/templates/pageSuccess.php
>
> >>> Here you can manage all pages contents.
>
Daniel Lohse
Dec 1, 2009, 8:41:04 AM12/1/09
to diem-...@googlegroups.com
I do understand that but there's also the problem that you're using HTML5 tags (like <header>) and that doesn't validate for XHTML 1.0 Strict. :(
Also, when looking at the index.php the doctype I can see is: <!DOCTYPE html> Something's definitely wrong there!
Daniel
Also, when looking at the index.php the doctype I can see is: <!DOCTYPE html> Something's definitely wrong there!
Daniel
thibault
Dec 1, 2009, 8:44:03 AM12/1/09
to diem-...@googlegroups.com
<!DOCTYPE html> is the recommendend doctype declaration for html5.
Diem defaults to html5 but you still can use xhtml. It will replace
all html5 tags with divs.
Look to your apps/front/config/dm/config.yml file:
html:
doctype:
name: 'html' # Doctype name (
'html', 'xhtml' )
version: '5' # Doctype xhtml
version ( '1.0', '1.1' ) or html version ( '4', '5' )
compliance: 'transitional' # Doctype xhtml compliance
( 'strict', 'transitional' )
2009/12/1 Daniel Lohse <annism...@googlemail.com>:
Diem defaults to html5 but you still can use xhtml. It will replace
all html5 tags with divs.
Look to your apps/front/config/dm/config.yml file:
html:
doctype:
name: 'html' # Doctype name (
'html', 'xhtml' )
version: '5' # Doctype xhtml
version ( '1.0', '1.1' ) or html version ( '4', '5' )
compliance: 'transitional' # Doctype xhtml compliance
( 'strict', 'transitional' )
2009/12/1 Daniel Lohse <annism...@googlemail.com>:
Daniel Lohse
Dec 1, 2009, 8:49:11 AM12/1/09
to diem-...@googlegroups.com
Editing that configuration file to look like this was the first thing I did a few days ago ;-)
html:
doctype:
name: xhtml # Doctype name ( 'html', 'xhtml' )
version: 1.0 # Doctype xhtml version ( '1.0', '1.1' ) or html version ( '4', '5' )
compliance: strict # Doctype xhtml compliance ( 'strict', 'transitional' )
Still, the site is still as I posted it before; wrong Doctype and HTML5 tags in the source. :(
Daniel
html:
doctype:
name: xhtml # Doctype name ( 'html', 'xhtml' )
version: 1.0 # Doctype xhtml version ( '1.0', '1.1' ) or html version ( '4', '5' )
compliance: strict # Doctype xhtml compliance ( 'strict', 'transitional' )
Still, the site is still as I posted it before; wrong Doctype and HTML5 tags in the source. :(
Daniel
thibault
Dec 1, 2009, 9:09:31 AM12/1/09
to diem-...@googlegroups.com
Ok, thanks for the bug report.
It's fixed in latest svn.
2009/12/1 Daniel Lohse <annism...@googlemail.com>:
It's fixed in latest svn.
2009/12/1 Daniel Lohse <annism...@googlemail.com>:
Daniel Lohse
Dec 1, 2009, 9:20:31 AM12/1/09
to diem-...@googlegroups.com
Thanks, but it's still not 100% correct.
This is what's generated: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
This is what need to be generated: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Notice the "1" => "1.0". ;-)
Daniel
This is what's generated: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
This is what need to be generated: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Notice the "1" => "1.0". ;-)
Daniel
thibault
Dec 1, 2009, 9:25:25 AM12/1/09
to diem-...@googlegroups.com
It's because yaml transforms 1.0 into an integer : 1.
Now Diem knows how to deal with it.
Fix submitted
2009/12/1 Daniel Lohse <annism...@googlemail.com>:
Now Diem knows how to deal with it.
Fix submitted
2009/12/1 Daniel Lohse <annism...@googlemail.com>:
Daniel Lohse
Dec 2, 2009, 8:46:22 PM12/2/09
to diem-...@googlegroups.com
On 2009-12-01, at 1/December, 2:21 PM, ornicar wrote:
> "I thought the areas/zones were only rendered fully when a admin user (translator, webmaster etc.) accessed the site from the dev environment, and only in this combination.
> In all other cases only the content of the areas is rendered and no diem front editing code."
>
> I totally understand. I tried to do so one year ago. But there's a problem.
>
> When the template/CSS writer creates the site, he is always logged, and so the html code contains diem tags and classes. So he can rely on them for writing CSS.
> If some tags and classes disappear when he logs out, it could break the site style.
We recently had the discussion I quoted below. With ALPHA6 arriving, you added a style that replaced my background on a footer with a gray background-color.
> In all other cases only the content of the areas is rendered and no diem front editing code."
>
> I totally understand. I tried to do so one year ago. But there's a problem.
>
> When the template/CSS writer creates the site, he is always logged, and so the html code contains diem tags and classes. So he can rely on them for writing CSS.
> If some tags and classes disappear when he logs out, it could break the site style.
I probably just can't accept Diem rendering its helper divs (amongst other things) into the finished site layout. Also, when migrating an existing site to Diem this is just not going to work as the styles are already finished and your remark:
> So he can rely on them for writing CSS.
> If some tags and classes disappear when he logs out, it could break the site style.
How hard would it be to package this change to not render any Diem-specific markup/classes/ids into the finished production site into a plugin or making it at least configurable?
I probably didn't look hard enough, as I could figure this out by myself. But, as I always say, Diem is just so big. :)
Daniel
ornicar
Dec 3, 2009, 7:49:19 AM12/3/09
to diem-users
Ok, thanks for sharing your opinion on this important topic.
You're absolutely right, there must be a way to drop diem tags on prod
env.
The very good news is that all Diem internal views are object
oriented, and managed by the service container.
The page_helper service is responsible for rendering areas, zones and
widgets.
If we look into dmFrontPlugin/config/dm/services.yml, l.39, we see:
page_helper.class: dmFrontPageHelper # Responsible for
rendering the front content.
page_helper.view_class: dmFrontPageHelper
page_helper.edit_class: dmFrontPageEditHelper
It means that the page_helper service already has two implementation
classes.
When user has "front_edit" permission, page_helper.edit_class is used
and page_helper is handled by dmFrontPageEditHelper class.
For other users, page_helper.view_class is used and page_helper is
handled by dmFrontPageHelper class.
You may replace the page_helper.view_class and page_helper.edit_class
parameters to use your own classes.
But I prefer your idea to be integrated to Diem.
I think the best is to add an configuration setting in apps/front/
config/dm/config.yml:
all:
html:
no_diem_markup: true # Remove all diem markup when user
doesn't have the "front_edit" permission. Defaults to false.
And then, make dmFrontPageHelper render less markup.
Well, actually, the markup is the following for non-authenticated
user :
<div class="dm_area %area_name%"> // area : the area name ( e.g.
dm_layout_top ) is used as a class
<div class="dm_zones"> // zones list
<div class="dm_zone %user_classes%"> // zone : the user specified
zone classes and width are applied here
<div class="dm_widgets"> // widgets list
<div class="dm_widget %module% %action%"> // widget : the
widget's module and action are used as classes. This IS useful.
<div class="dm_widget_inner %user_classes%"> // widget
inner : the user specified widget classes are applied here
... // widget content managed by user templates
</div>
</div>
</div>
</div>
</div>
</div>
When dm_html_no_diem_markup is set to true, it may become :
<div class="%area_name%"> // area : the area name ( e.g.
dm_layout_top ) is used as a class
<div class="%zone_user_classes%"> // zone : the user specified zone
classes and width are applied here
<div class="%widget_module% %widget_action%"> // widget : the
widget's module and action are used as classes. This IS useful.
<div class="%user_classes%"> // widget inner : the user
specified widget classes are applied here
... // widget content managed by user templates
</div>
</div>
</div>
</div>
There are still 4 div levels before your templates, but as Diem allows
to set classes to your zones and widgets, I can't imagine a better
solution for now.
What's your opinion ?
You're absolutely right, there must be a way to drop diem tags on prod
env.
The very good news is that all Diem internal views are object
oriented, and managed by the service container.
The page_helper service is responsible for rendering areas, zones and
widgets.
If we look into dmFrontPlugin/config/dm/services.yml, l.39, we see:
page_helper.class: dmFrontPageHelper # Responsible for
rendering the front content.
page_helper.view_class: dmFrontPageHelper
page_helper.edit_class: dmFrontPageEditHelper
It means that the page_helper service already has two implementation
classes.
When user has "front_edit" permission, page_helper.edit_class is used
and page_helper is handled by dmFrontPageEditHelper class.
For other users, page_helper.view_class is used and page_helper is
handled by dmFrontPageHelper class.
You may replace the page_helper.view_class and page_helper.edit_class
parameters to use your own classes.
But I prefer your idea to be integrated to Diem.
I think the best is to add an configuration setting in apps/front/
config/dm/config.yml:
all:
html:
no_diem_markup: true # Remove all diem markup when user
doesn't have the "front_edit" permission. Defaults to false.
And then, make dmFrontPageHelper render less markup.
Well, actually, the markup is the following for non-authenticated
user :
<div class="dm_area %area_name%"> // area : the area name ( e.g.
dm_layout_top ) is used as a class
<div class="dm_zones"> // zones list
<div class="dm_zone %user_classes%"> // zone : the user specified
zone classes and width are applied here
<div class="dm_widgets"> // widgets list
<div class="dm_widget %module% %action%"> // widget : the
widget's module and action are used as classes. This IS useful.
<div class="dm_widget_inner %user_classes%"> // widget
inner : the user specified widget classes are applied here
... // widget content managed by user templates
</div>
</div>
</div>
</div>
</div>
</div>
When dm_html_no_diem_markup is set to true, it may become :
<div class="%area_name%"> // area : the area name ( e.g.
dm_layout_top ) is used as a class
<div class="%zone_user_classes%"> // zone : the user specified zone
classes and width are applied here
<div class="%widget_module% %widget_action%"> // widget : the
widget's module and action are used as classes. This IS useful.
<div class="%user_classes%"> // widget inner : the user
specified widget classes are applied here
... // widget content managed by user templates
</div>
</div>
</div>
</div>
There are still 4 div levels before your templates, but as Diem allows
to set classes to your zones and widgets, I can't imagine a better
solution for now.
What's your opinion ?
Daniel Lohse
Dec 3, 2009, 8:41:19 AM12/3/09
to diem-...@googlegroups.com
I first had to edit your post (below) as Google somewhat mangled the line length and it was barely understandable.
So, as I guessed, your usage of the dependency injection component is really quite awesome (that's probably what we can expect with Symfony 2.0)! :)
I'll add my comments inline to the original post below.
On 2009-12-03, at 3/December, 1:49 PM, ornicar wrote:
> Ok, thanks for sharing your opinion on this important topic.
>
> You're absolutely right, there must be a way to drop diem tags on prod env.
> The very good news is that all Diem internal views are object oriented, and managed by the service container.
Yay! :)
>
> The page_helper service is responsible for rendering areas, zones and widgets.
> If we look into dmFrontPlugin/config/dm/services.yml, l.39, we see:
>
> page_helper.class: dmFrontPageHelper # Responsible for rendering the front content.
> page_helper.view_class: dmFrontPageHelper
> page_helper.edit_class: dmFrontPageEditHelper
>
> It means that the page_helper service already has two implementation classes.
>
> When user has "front_edit" permission, page_helper.edit_class is used and page_helper is handled by dmFrontPageEditHelper class.
> For other users, page_helper.view_class is used and page_helper is handled by dmFrontPageHelper class.
>
> You may replace the page_helper.view_class and page_helper.edit_class parameters to use your own classes.
> But I prefer your idea to be integrated to Diem.
Thanks, that would be awesome to have it in the core.
>
> I think the best is to add an configuration setting in apps/front/config/dm/config.yml:
> all:
> html:
> no_diem_markup: true # Remove all diem markup when user doesn't have the "front_edit" permission. Defaults to false.
Exactly what I was thinking, good idea.
> And then, make dmFrontPageHelper render less markup.
>
> Well, actually, the markup is the following for non-authenticated user:
>
> <div class="dm_area %area_name%"> // area : the area name ( e.g. dm_layout_top ) is used as a class
>
> <div class="dm_zones"> // zones list
>
> <div class="dm_zone %user_classes%"> // zone : the user specified zone classes and width are applied here
>
> <div class="dm_widgets"> // widgets list
>
> <div class="dm_widget %module% %action%"> // widget : the widget's module and action are used as classes. This IS useful.
>
> <div class="dm_widget_inner %user_classes%"> // widget inner : the user specified widget classes are applied here
>
> ... // widget content managed by user templates
>
> </div>
> </div>
> </div>
> </div>
> </div>
> </div>
>
> When dm_html_no_diem_markup is set to true, it may become :
>
> <div class="%area_name%"> // area : the area name ( e.g. dm_layout_top ) is used as a class
>
> <div class="%zone_user_classes%"> // zone : the user specified zone classes and width are applied here
Actually, I don't think that the "width" is a useful option to have because I think that for complex projects, a CSS framework should be used (e.g. Blueprint or the like). And Blueprint works by adding classes, not applying width directly to the markup.
>
> <div class="%widget_module% %widget_action%"> // widget : the widget's module and action are used as classes. This IS useful.
Yes, I think that this is useful, but: it should probably be prefixed (!) by something even you don't use in your styles. The point being, that modules and actions are mostly pretty short and tend to have universal names. This could then easily crash your whole styles and you didn't even notice.
>
> <div class="%user_classes%"> // widget inner : the user specified widget classes are applied here
As I can imagine having widgets that don't wrap in divs (special paragraphs as widgets and so forth) I'd argue that this is not needed. If I create a widget that wraps, say, multiple paragraph widgets (is this possible?) I'd want to add this wrapper div *inside* the widget class to manage it more easily and if I don't want to wrap the widget content I don't have to. This is better managed inside the widget itself.
>
> ... // widget content managed by user templates
>
> </div>
> </div>
> </div>
> </div>
>
> There are still 4 div levels before your templates, but as Diem allows to set classes to your zones and widgets, I can't imagine a better solution for now.
>
> What's your opinion ?
So, that leaves me with this conclusion: your willingness to listen to user/developer feedback is unbelievably good. :) Thanks!
And when you do implement this and you're not going far enough for me, I can easily extend your work and kill even more wrapper divs. :D
But I do think that this is the right approach we're taking here, especially because it's still highly configurable and, if need be, customizable.
Daniel
So, as I guessed, your usage of the dependency injection component is really quite awesome (that's probably what we can expect with Symfony 2.0)! :)
I'll add my comments inline to the original post below.
On 2009-12-03, at 3/December, 1:49 PM, ornicar wrote:
> Ok, thanks for sharing your opinion on this important topic.
>
> You're absolutely right, there must be a way to drop diem tags on prod env.
> The very good news is that all Diem internal views are object oriented, and managed by the service container.
>
> The page_helper service is responsible for rendering areas, zones and widgets.
> If we look into dmFrontPlugin/config/dm/services.yml, l.39, we see:
>
> page_helper.class: dmFrontPageHelper # Responsible for rendering the front content.
> page_helper.view_class: dmFrontPageHelper
> page_helper.edit_class: dmFrontPageEditHelper
>
> It means that the page_helper service already has two implementation classes.
>
> When user has "front_edit" permission, page_helper.edit_class is used and page_helper is handled by dmFrontPageEditHelper class.
> For other users, page_helper.view_class is used and page_helper is handled by dmFrontPageHelper class.
>
> You may replace the page_helper.view_class and page_helper.edit_class parameters to use your own classes.
> But I prefer your idea to be integrated to Diem.
>
> I think the best is to add an configuration setting in apps/front/config/dm/config.yml:
> all:
> html:
> no_diem_markup: true # Remove all diem markup when user doesn't have the "front_edit" permission. Defaults to false.
> And then, make dmFrontPageHelper render less markup.
>
> Well, actually, the markup is the following for non-authenticated user:
>
> <div class="dm_area %area_name%"> // area : the area name ( e.g. dm_layout_top ) is used as a class
>
> <div class="dm_zones"> // zones list
>
> <div class="dm_zone %user_classes%"> // zone : the user specified zone classes and width are applied here
>
> <div class="dm_widgets"> // widgets list
>
> <div class="dm_widget %module% %action%"> // widget : the widget's module and action are used as classes. This IS useful.
>
> <div class="dm_widget_inner %user_classes%"> // widget inner : the user specified widget classes are applied here
>
> ... // widget content managed by user templates
>
> </div>
> </div>
> </div>
> </div>
> </div>
> </div>
>
> When dm_html_no_diem_markup is set to true, it may become :
>
> <div class="%area_name%"> // area : the area name ( e.g. dm_layout_top ) is used as a class
>
> <div class="%zone_user_classes%"> // zone : the user specified zone classes and width are applied here
>
> <div class="%widget_module% %widget_action%"> // widget : the widget's module and action are used as classes. This IS useful.
>
> <div class="%user_classes%"> // widget inner : the user specified widget classes are applied here
>
> ... // widget content managed by user templates
>
> </div>
> </div>
> </div>
> </div>
>
> There are still 4 div levels before your templates, but as Diem allows to set classes to your zones and widgets, I can't imagine a better solution for now.
>
> What's your opinion ?
And when you do implement this and you're not going far enough for me, I can easily extend your work and kill even more wrapper divs. :D
But I do think that this is the right approach we're taking here, especially because it's still highly configurable and, if need be, customizable.
Daniel
ornicar
Dec 3, 2009, 10:41:46 AM12/3/09
to diem-users
As an introduction, I understand your willingness to kill unnecessary
divs, but I follow another approach.
As described in "The cathedral and the bazaar", Diem first objective
is to make things simpler for the user.
In some cases, efficiency may be sacrificed to simplicity. That's the
reason why many div wraps are used.
Additionally, as div tags are semantically null, there is no problem
in using lots of them. Some argue about performances and document
size. I don't have numbers but I'm certain the difference is just
imperceptible.
This is my personal opinion, and not the Diem one. Now, let's discuss
on how to kill these %$! divs.
> Actually, I don't think that the "width" is a useful option to have because I think that for complex projects, a CSS framework should be used (e.g. Blueprint or the like). And Blueprint works by adding classes, not applying width directly to the markup.
Yes. The zone "width" field has always been higly controversial. It
exists only to allow webmasters who know nothing about CSS to create
columns easily. For example they can set width to "50%" and get a two
columns area. But is letting people who know nothing about CSS modify
the site content a good idea ?
I prefer letting the site's developer answer to this question. That's
why I just added the zone_form service to the front service container.
By default the zone form uses the width field. But you can remove it
by changing the zone_form service class in your apps/front/config/dm/
services.yml:
parameters:
zone_form.class: myZoneFrontForm
Then, create apps/front/lib/myZoneFrontForm.php:
class myZoneFrontForm extends DmZoneFrontForm
{
public function configure()
{
parent::configure(); // let Diem configure the form
unset($this['width']); // remove this higly controversial field
}
}
I hope it makes you happier.
> > <div class="%widget_module% %widget_action%"> // widget : the widget's module and action are used as classes. This IS useful.
>
> Yes, I think that this is useful, but: it should probably be prefixed (!) by something even you don't use in your styles. The point being, that modules and actions are mostly pretty short and tend to have universal names. This could then easily crash your whole styles and you didn't even notice.
You're probably right. But what kind of prefix could be used ?
"module_" and "action_" ? The problem is that it will break BC, and
diem-project.org will explode. Help me cause I'm confused.
> > <div class="%user_classes%"> // widget inner : the user specified widget classes are applied here
>
> As I can imagine having widgets that don't wrap in divs (special paragraphs as widgets and so forth) I'd argue that this is not needed. If I create a widget that wraps, say, multiple paragraph widgets (is this possible?) I'd want to add this wrapper div *inside* the widget class to manage it more easily and if I don't want to wrap the widget content I don't have to. This is better managed inside the widget itself.
As for now, you cannot wrap widgets inside widgets. If we allow to do
so, it will become quite complex. Widgets are wrapped by zones, so you
have to insert multiple text widgets into your zone.
I'll sudy possibility to merge this div with the previous one. If we
do so, it has to apply both on view and edit mode. It will break BC.
We have to think about all compatibility breaks we may bring and
package all of them onto a Diem version. With a migration guide. Or a
BC configuration ( doesn't sound very good to me )
> And when you do implement this and you're not going far enough for me, I can easily extend your work and kill even more wrapper divs. :D
> But I do think that this is the right approach we're taking here, especially because it's still highly configurable and, if need be, customizable.
Yeah, everything needs to be customizable. This really is not a
problem. The real problem when creating a CMS is to provide sensible
defaults.
divs, but I follow another approach.
As described in "The cathedral and the bazaar", Diem first objective
is to make things simpler for the user.
In some cases, efficiency may be sacrificed to simplicity. That's the
reason why many div wraps are used.
Additionally, as div tags are semantically null, there is no problem
in using lots of them. Some argue about performances and document
size. I don't have numbers but I'm certain the difference is just
imperceptible.
This is my personal opinion, and not the Diem one. Now, let's discuss
on how to kill these %$! divs.
> Actually, I don't think that the "width" is a useful option to have because I think that for complex projects, a CSS framework should be used (e.g. Blueprint or the like). And Blueprint works by adding classes, not applying width directly to the markup.
exists only to allow webmasters who know nothing about CSS to create
columns easily. For example they can set width to "50%" and get a two
columns area. But is letting people who know nothing about CSS modify
the site content a good idea ?
I prefer letting the site's developer answer to this question. That's
why I just added the zone_form service to the front service container.
By default the zone form uses the width field. But you can remove it
by changing the zone_form service class in your apps/front/config/dm/
services.yml:
parameters:
zone_form.class: myZoneFrontForm
Then, create apps/front/lib/myZoneFrontForm.php:
class myZoneFrontForm extends DmZoneFrontForm
{
public function configure()
{
parent::configure(); // let Diem configure the form
unset($this['width']); // remove this higly controversial field
}
}
I hope it makes you happier.
> > <div class="%widget_module% %widget_action%"> // widget : the widget's module and action are used as classes. This IS useful.
>
> Yes, I think that this is useful, but: it should probably be prefixed (!) by something even you don't use in your styles. The point being, that modules and actions are mostly pretty short and tend to have universal names. This could then easily crash your whole styles and you didn't even notice.
"module_" and "action_" ? The problem is that it will break BC, and
diem-project.org will explode. Help me cause I'm confused.
> > <div class="%user_classes%"> // widget inner : the user specified widget classes are applied here
>
> As I can imagine having widgets that don't wrap in divs (special paragraphs as widgets and so forth) I'd argue that this is not needed. If I create a widget that wraps, say, multiple paragraph widgets (is this possible?) I'd want to add this wrapper div *inside* the widget class to manage it more easily and if I don't want to wrap the widget content I don't have to. This is better managed inside the widget itself.
so, it will become quite complex. Widgets are wrapped by zones, so you
have to insert multiple text widgets into your zone.
I'll sudy possibility to merge this div with the previous one. If we
do so, it has to apply both on view and edit mode. It will break BC.
We have to think about all compatibility breaks we may bring and
package all of them onto a Diem version. With a migration guide. Or a
BC configuration ( doesn't sound very good to me )
> And when you do implement this and you're not going far enough for me, I can easily extend your work and kill even more wrapper divs. :D
> But I do think that this is the right approach we're taking here, especially because it's still highly configurable and, if need be, customizable.
problem. The real problem when creating a CMS is to provide sensible
defaults.
Daniel Lohse
Dec 3, 2009, 5:56:59 PM12/3/09
to diem-...@googlegroups.com
On 2009-12-03, at 3/December, 4:41 PM, ornicar wrote:
> As an introduction, I understand your willingness to kill unnecessary divs, but I follow another approach.
> As described in "The cathedral and the bazaar", Diem first objective is to make things simpler for the user.
> In some cases, efficiency may be sacrificed to simplicity. That's the reason why many div wraps are used.
> Additionally, as div tags are semantically null, there is no problem in using lots of them. Some argue about performances and document size. I don't have numbers but I'm certain the difference is just imperceptible.
> This is my personal opinion, and not the Diem one. Now, let's discuss on how to kill these %$! divs.
>
>> Actually, I don't think that the "width" is a useful option to have because I think that for complex projects, a CSS framework should be used (e.g. Blueprint or the like). And Blueprint works by adding classes, not applying width directly to the markup.
>
> Yes. The zone "width" field has always been higly controversial. It exists only to allow webmasters who know nothing about CSS to create columns easily. For example they can set width to "50%" and get a two columns area. But is letting people who know nothing about CSS modify the site content a good idea ?
>
> I prefer letting the site's developer answer to this question. That's why I just added the zone_form service to the front service container. By default the zone form uses the width field. But you can remove it by changing the zone_form service class in your apps/front/config/dm/services.yml:
>
> parameters:
> zone_form.class: myZoneFrontForm
>
> Then, create apps/front/lib/myZoneFrontForm.php:
>
> class myZoneFrontForm extends DmZoneFrontForm
> {
> public function configure()
> {
> parent::configure(); // let Diem configure the form
>
> unset($this['width']); // remove this higly controversial field
> }
> }
>
> I hope it makes you happier.
>
>>> <div class="%widget_module% %widget_action%"> // widget : the widget's module and action are used as classes. This IS useful.
>>
>> Yes, I think that this is useful, but: it should probably be prefixed (!) by something even you don't use in your styles. The point being, that modules and actions are mostly pretty short and tend to have universal names. This could then easily crash your whole styles and you didn't even notice.
>
Yes, maybe "diem_module_" and "diem_action_". I don't think you'll use these. Or you can't after you choose these. :D
>
>>> <div class="%user_classes%"> // widget inner : the user specified widget classes are applied here
>>
>> As I can imagine having widgets that don't wrap in divs (special paragraphs as widgets and so forth) I'd argue that this is not needed. If I create a widget that wraps, say, multiple paragraph widgets (is this possible?) I'd want to add this wrapper div *inside* the widget class to manage it more easily and if I don't want to wrap the widget content I don't have to. This is better managed inside the widget itself.
>
> As for now, you cannot wrap widgets inside widgets. If we allow to do so, it will become quite complex. Widgets are wrapped by zones, so you have to insert multiple text widgets into your zone.
> We have to think about all compatibility breaks we may bring and package all of them onto a Diem version. With a migration guide. Or a BC configuration ( doesn't sound very good to me )
No, no, no. :) These are ALPHA releases! Yes, it needs to be documented but there's no need for a special task or something automagic like that.
And: I don't think you'd want to use Diem for big production websites just now. I mean, diem-project.com is really great but you have to admin that you could change a lot in the next, say, 6 weeks. I have seen you create commits that blew my mind when I saw the number of files changed/added. :)
For now I handle it like this. If there's a new Diem version I try some new stuff and then I just do ./symfony dm:setup --clear-db and even if something changes, I should be golden. Or am I wrong in saying that?
>
>> And when you do implement this and you're not going far enough for me, I can easily extend your work and kill even more wrapper divs. :D
>> But I do think that this is the right approach we're taking here, especially because it's still highly configurable and, if need be, customizable.
>
> Yeah, everything needs to be customizable. This really is not a problem. The real problem when creating a CMS is to provide sensible defaults.
Daniel
Matthieu Bontemps
Dec 4, 2009, 3:40:27 AM12/4/09
to diem-...@googlegroups.com
Just my 2 cents about BC.
--
Matthieu Bontemps
Agence web Le Canape Rouge // Directeur Technique, fondateur
http://www.canape-rouge.fr
http://twitter.com/mbontemps
Nos dernières réalisations :
http://job.letsbuyit.com
http://www.happyhourhoover.com
http://www.wiki-avis.fr
I must agree with Daniel on this one.
These are good times for community feedback, breaking changes, and reflexion around the functionalities.
I don't say we should break everything, because Diem is already a very good product.
But I say breaking things shouldn't be an issue (at this time...). It allows us to move quickly toward a 5.0 release, without having the burden of maintaining old choices.
--
Matthieu Bontemps
Agence web Le Canape Rouge // Directeur Technique, fondateur
http://www.canape-rouge.fr
http://twitter.com/mbontemps
Nos dernières réalisations :
http://job.letsbuyit.com
http://www.happyhourhoover.com
http://www.wiki-avis.fr
Reply all
Reply to author
Forward
0 new messages