Re: How to handle components and filesystem wysiwyg design?
I have menu and locale selection in my border and some other stuff and I Regardless of wether you use the Border pattern or not you are not forced to duplicate content in the static versions. Whatever is between the div tags are replaced with the template of your Border/NavigationPane/Header/Footer component. It is merely a good idea to have sample markup there to be able to verify the static layout. I find that the Border pattern forces you to add a lot of dead(ignored by tapestry) html if you want to maintain the template viewable directly from the file. don't want to put this in all pages. But keeping the static version in all My main objective is to have as little as possible dead html. pages seems almost as tedious. Or maybe I'll just add the css in all pages Are you using inline css? why not proper stylesheets in a separate .css file? and then the design guy will have to imagine all the menu stuff around each page body. But I'm not happy with this. Hmm, ok, let me suggest that you use Home.htm as the main static layout in the sense that all the html is kept up to date wether ignored by Tapestry or not. Make a component called Menu and give it a template containing the html within the menu including the enclosing div. Put jwcid=@Menu on the relevant div in Home.htm. Assuming your designer is up to scratch the menu will be an unordered list (http://alistapart.com/articles/dropdowns/) Then update all other page templates with div id=menu jwcid=@Menuullia href=#One/a/lilia href=#One/a/li/ul/div You are now able to verify the design visually and maintain it with little overhead. Of course you cannot verify the links in the static design, but that would be pointless anyhow as they do not reflect the actual site. Malin On 8/21/06, hv @ Fashion Content [EMAIL PROTECTED] wrote: This is why I don't use the Border component pattern, but add the basic structure to all pages. With a decent css design and some NavigationPane/Header/Footer components you can keep the additional tags quite low, and allow the designer maximum freedom. Something like: html jwcid=shell head jwcid=$remove$ ... /head body jwcid=body div id=navbar jwcid=navbarulliLink/li/ul/div div id=content .. /div div id=footer jwcid=footercopyright etc./div Henrik Malin Ljungh [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] I thought one of the main advantages of Tapestry was that you can open your html files directly from the filesystem and see how they actually will look when rendered by the Tapestry servlet. But now when my design guy is about to do the css this is not the case, and I guess it is because I have not entered static bodies to the components that renders its own body in a proper way. And the biggest problem is maybe the border component. Am I supposed to insert a static version of my border component in each and every page to get this to work properly? What if I change the border component - I will have to change all my files... I realise this is not a critical runtime issue, but I thought maybe I have missed something here. How do you guys handle this? Malin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle components and filesystem wysiwyg design?
I have tried to describe my approach in the following wiki http://wiki.apache.org/tapestry/WysiwygWithoutBorder hv @ Fashion Content [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] I have menu and locale selection in my border and some other stuff and I Regardless of wether you use the Border pattern or not you are not forced to duplicate content in the static versions. Whatever is between the div tags are replaced with the template of your Border/NavigationPane/Header/Footer component. It is merely a good idea to have sample markup there to be able to verify the static layout. I find that the Border pattern forces you to add a lot of dead(ignored by tapestry) html if you want to maintain the template viewable directly from the file. don't want to put this in all pages. But keeping the static version in all My main objective is to have as little as possible dead html. pages seems almost as tedious. Or maybe I'll just add the css in all pages Are you using inline css? why not proper stylesheets in a separate .css file? and then the design guy will have to imagine all the menu stuff around each page body. But I'm not happy with this. Hmm, ok, let me suggest that you use Home.htm as the main static layout in the sense that all the html is kept up to date wether ignored by Tapestry or not. Make a component called Menu and give it a template containing the html within the menu including the enclosing div. Put jwcid=@Menu on the relevant div in Home.htm. Assuming your designer is up to scratch the menu will be an unordered list (http://alistapart.com/articles/dropdowns/) Then update all other page templates with div id=menu jwcid=@Menuullia href=#One/a/lilia href=#One/a/li/ul/div You are now able to verify the design visually and maintain it with little overhead. Of course you cannot verify the links in the static design, but that would be pointless anyhow as they do not reflect the actual site. Malin On 8/21/06, hv @ Fashion Content [EMAIL PROTECTED] wrote: This is why I don't use the Border component pattern, but add the basic structure to all pages. With a decent css design and some NavigationPane/Header/Footer components you can keep the additional tags quite low, and allow the designer maximum freedom. Something like: html jwcid=shell head jwcid=$remove$ ... /head body jwcid=body div id=navbar jwcid=navbarulliLink/li/ul/div div id=content .. /div div id=footer jwcid=footercopyright etc./div Henrik Malin Ljungh [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] I thought one of the main advantages of Tapestry was that you can open your html files directly from the filesystem and see how they actually will look when rendered by the Tapestry servlet. But now when my design guy is about to do the css this is not the case, and I guess it is because I have not entered static bodies to the components that renders its own body in a proper way. And the biggest problem is maybe the border component. Am I supposed to insert a static version of my border component in each and every page to get this to work properly? What if I change the border component - I will have to change all my files... I realise this is not a critical runtime issue, but I thought maybe I have missed something here. How do you guys handle this? Malin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to handle components and filesystem wysiwyg design?
Hi Malin, Instead of keep a static copy of border on each page, you can do the opposite. I usually keep a Dumb copy of my border, without jwcid's, in a resource directory, out of the app context, but under version control, and left the space where the body is rendered blank (better if you put comments on start and end of render body space). When I want to style some page, I copy-and-paste the page to the dumb border RenderBody space, and add the css link that I want to edit. Then I can see the entire page, with the border and edit in a WYSIWYG editor. So, after the designer finishes, I copy-and-paste back to the page template. If you trust your designers, you can do this with the truth border, without a dumb copy, but keep then out of jwcid's! I already made the error of keeping a static copy of border in each page, but as your app grows, this become impossible to maintain! Mael On 8/21/06, Malin Ljungh [EMAIL PROTECTED] wrote: Hmm, OK, I guess there is no good solution to this. I have menu and locale selection in my border and some other stuff and I don't want to put this in all pages. But keeping the static version in all pages seems almost as tedious. Or maybe I'll just add the css in all pages and then the design guy will have to imagine all the menu stuff around each page body. But I'm not happy with this. Malin On 8/21/06, hv @ Fashion Content [EMAIL PROTECTED] wrote: This is why I don't use the Border component pattern, but add the basic structure to all pages. With a decent css design and some NavigationPane/Header/Footer components you can keep the additional tags quite low, and allow the designer maximum freedom. Something like: html jwcid=shell head jwcid=$remove$ ... /head body jwcid=body div id=navbar jwcid=navbarulliLink/li/ul/div div id=content .. /div div id=footer jwcid=footercopyright etc./div Henrik Malin Ljungh [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] I thought one of the main advantages of Tapestry was that you can open your html files directly from the filesystem and see how they actually will look when rendered by the Tapestry servlet. But now when my design guy is about to do the css this is not the case, and I guess it is because I have not entered static bodies to the components that renders its own body in a proper way. And the biggest problem is maybe the border component. Am I supposed to insert a static version of my border component in each and every page to get this to work properly? What if I change the border component - I will have to change all my files... I realise this is not a critical runtime issue, but I thought maybe I have missed something here. How do you guys handle this? Malin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to handle components and filesystem wysiwyg design?
I thought one of the main advantages of Tapestry was that you can open your html files directly from the filesystem and see how they actually will look when rendered by the Tapestry servlet. But now when my design guy is about to do the css this is not the case, and I guess it is because I have not entered static bodies to the components that renders its own body in a proper way. And the biggest problem is maybe the border component. Am I supposed to insert a static version of my border component in each and every page to get this to work properly? What if I change the border component - I will have to change all my files... I realise this is not a critical runtime issue, but I thought maybe I have missed something here. How do you guys handle this? Malin
Re: How to handle components and filesystem wysiwyg design?
This is why I don't use the Border component pattern, but add the basic structure to all pages. With a decent css design and some NavigationPane/Header/Footer components you can keep the additional tags quite low, and allow the designer maximum freedom. Something like: html jwcid=shell head jwcid=$remove$ ... /head body jwcid=body div id=navbar jwcid=navbarulliLink/li/ul/div div id=content .. /div div id=footer jwcid=footercopyright etc./div Henrik Malin Ljungh [EMAIL PROTECTED] skrev i en meddelelse news:[EMAIL PROTECTED] I thought one of the main advantages of Tapestry was that you can open your html files directly from the filesystem and see how they actually will look when rendered by the Tapestry servlet. But now when my design guy is about to do the css this is not the case, and I guess it is because I have not entered static bodies to the components that renders its own body in a proper way. And the biggest problem is maybe the border component. Am I supposed to insert a static version of my border component in each and every page to get this to work properly? What if I change the border component - I will have to change all my files... I realise this is not a critical runtime issue, but I thought maybe I have missed something here. How do you guys handle this? Malin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
