Sorry but I couldn't think on a proper title for this thread. The thing is: today something challenged me and I got totally lost.
I have this area on our site that can be divided in multiple columns just by adding "DIV" tags. It won't just make the colunms but the nice boxes as you can see in the attached picture.
The problem is that the end user doesn't know a thing about html and won't keep switching back and forth from the HTML editor to edit tags.
I'd like to know if is there a way to add a code snippet or something like that. The idea is to have a place where the user can select a template (coluns/colors) as you can see in the picture and just edit the content, so he don't need to worry about html tags.
Thanks a lot. I will give it a try. One thing though, since i have to change the "/config/tinyMceConfig.config", I will probably have to redo it after all upgrades, right?
Have the boxes as subnodes to the page and diffrent properties for choosing color, div size and content. Then for each subnode create a div with the choosen styles and content.
Hmm... that's interesting. But your theory raise some questions:
a) Can the system know how many boxes are in one row? Or You mean something like this? HomePage --Row1 ----Box-One-Third ----Box-Two-Third --Row2 ----Box1-Full_Width
b) How can I limit how many boxes (subnodes) per row (parent node)? c) How can I validate the width? e.g:
If the user create just one box, it must be full width, I he creates one box with two thirds, hus must create another one which can only be one third, an so on.
d) For a fixed position at the bottom of the screen (as it is in the picture) it works fine but how can I define the position if I want it in different positions depending of the page?
If you consider the subnodes approach I think I would refine the suggestion by Johan like this.
Create a new document type, which should be the root of your layout repository. You can call it "Layout repo". Then I would create a specific document type as Johan is mentioning where you can make properties for the width etc.
Then you can define the different boxes for the node in one place and then on your content node use a multiple picker, which allows you to select the boxes you need for the specific page.
This way you don't clutter up the content branch with stuff that is not content related.
If I understand your issue correctly I think most of the questions above can be handled by providing the document type for a layoutbox with the proper properties, which gives you full control on how to do things. You should probably also consider a naming-concention when you create the boxes so it makes sense when what should be used etc.
Hope this helps a bit.
Regarding the question about the tinyMceConfig settings I'm not sure what you mean? If you're thinking about what happens when you upgrade Umbraco then yes, if you need to overwrite the config folder you'll need to add the section once again. But you should always have a backup of the old config files and then I guess it's a matter of using something like winmerge to get the files merged.
I like this idea but I’m still a little confused.
Let’s say I have a document type with 3 properties: width, color and content.
This document type will be the equivalent to one of those boxes on the picture.
Them I have a repository as you said where I can keep these “boxes”
on.
Now, at the page level I can have a macro with a multiple
picker, as you suggested.
This macro will render one row. So to reproduce the effect in the picture I
would need to add the macro 7 times.
And finally the question:
How can I prevent the user from selecting more boxes/nodes
then he should? Or from selecting two or more boxes/nodes that you end up being
larger than the available width?
I know that a name convention and a little bit of attention
from the end user should do it but, you know end users.
Taking layout formatting to the next level
Hi there;
Sorry but I couldn't think on a proper title for this thread.
The thing is: today something challenged me and I got totally lost.
I have this area on our site that can be divided in multiple columns just by adding "DIV" tags.
It won't just make the colunms but the nice boxes as you can see in the attached picture.
The problem is that the end user doesn't know a thing about html and won't keep switching back and forth from the HTML editor to edit tags.
I'd like to know if is there a way to add a code snippet or something like that.
The idea is to have a place where the user can select a template (coluns/colors) as you can see in the picture and just edit the content, so he don't need to worry about html tags.
Hi CodeMaster
Maybe the option to use templates in the rich text editor is what you're looking for? http://our.umbraco.org/wiki/how-tos/enabling-the-%27template%27-plugin-for-tinymce
/Jan
Thanks a lot. I will give it a try.
One thing though, since i have to change the "/config/tinyMceConfig.config", I will probably have to redo it after all upgrades, right?
I woud probably solve like this:
Have the boxes as subnodes to the page and diffrent properties for choosing color, div size and content. Then for each subnode create a div with the choosen styles and content.
Hmm... that's interesting. But your theory raise some questions:
a) Can the system know how many boxes are in one row? Or You mean something like this?
HomePage
--Row1
----Box-One-Third
----Box-Two-Third
--Row2
----Box1-Full_Width
b) How can I limit how many boxes (subnodes) per row (parent node)?
c) How can I validate the width? e.g:
If the user create just one box, it must be full width,
I he creates one box with two thirds, hus must create another one which can only be one third, an so on.
d) For a fixed position at the bottom of the screen (as it is in the picture) it works fine but how can I define the position if I want it in different positions depending of the page?
Hi Codemaster
If you consider the subnodes approach I think I would refine the suggestion by Johan like this.
Create a new document type, which should be the root of your layout repository. You can call it "Layout repo". Then I would create a specific document type as Johan is mentioning where you can make properties for the width etc.
Then you can define the different boxes for the node in one place and then on your content node use a multiple picker, which allows you to select the boxes you need for the specific page.
This way you don't clutter up the content branch with stuff that is not content related.
If I understand your issue correctly I think most of the questions above can be handled by providing the document type for a layoutbox with the proper properties, which gives you full control on how to do things. You should probably also consider a naming-concention when you create the boxes so it makes sense when what should be used etc.
Hope this helps a bit.
Regarding the question about the tinyMceConfig settings I'm not sure what you mean? If you're thinking about what happens when you upgrade Umbraco then yes, if you need to overwrite the config folder you'll need to add the section once again. But you should always have a backup of the old config files and then I guess it's a matter of using something like winmerge to get the files merged.
/Jan
I like this idea but I’m still a little confused.
Let’s say I have a document type with 3 properties: width, color and content. This document type will be the equivalent to one of those boxes on the picture.
Them I have a repository as you said where I can keep these “boxes” on.
Now, at the page level I can have a macro with a multiple picker, as you suggested.
This macro will render one row. So to reproduce the effect in the picture I would need to add the macro 7 times.
And finally the question:
How can I prevent the user from selecting more boxes/nodes then he should? Or from selecting two or more boxes/nodes that you end up being larger than the available width?
I know that a name convention and a little bit of attention from the end user should do it but, you know end users.
is working on a reply...