Some pier related questions
Norbert Hartl
I looked at the code of bibliocello and I like the approach you took. I was thinking myself to utilize the command classes from pier for my own purpose. I thought it would need to fit for pier and my own model. And that were the reasons not to do it this way. But you did it the right way to separate the commands for pier and the model and to interconnect them on purpose.
My approach was to make virtual pages. I have a page that has two settings. A page that acts as a template for the virtual page and a class to lookup context object for that page. Whenever the children decoration does not find a page it looks if an object exists that fits the name in the url. If so a new page is created by cloning the template and deliver this to the client. This way it would have been possible to have a huge amount of objects without the need to have a page for every object. Second it would have been possible to manage a single template that changes the content of all pages of a kind. I made this to let people design the page easily.
But the approach is too complex and error prone. First I have a context object set in a pier structure that couples my model to the pier model. This is bad while exporting but also if pages are linked from within the site. It just doesn't work that good.
I like the way you did it but there still open points:
- creating a page is a one-time action. There is no way to alter the created pages afterwards in a systematical way. Do you think projects in bibliocello will need a system wide layout (or a layout for part of the page). What would be the way to adjust the layout of existing projects afterwards?
- maybe I missed that piece of code but how do you create a pier page if the project is created from REST?
I think there a few ways to deal with that. Layout specific things could be handled by:
- having system dependent stuff in the environment
- embed other documents in the projects document. There was quite a nice way but I would need to research it again
- have pages for e.g. projects share a single document. Don't know the problems here, yet
Does anybody of you have an opinion on this?
Norbert
Dale
On Aug 13, 2:40 am, Norbert Hartl <norbert.ha...@googlemail.com>
wrote:
>
> I looked at the code of bibliocello and I like the approach you took. I was thinking myself to utilize the command classes from pier for my own purpose. I thought it would need to fit for pier and my own model. And that were the reasons not to do it this way. But you did it the right way to separate the commands for pier and the model and to interconnect them on purpose.
>
> My approach was to make virtual pages. I have a page that has two settings. A page that acts as a template for the virtual page and a class to lookup context object for that page. Whenever the children decoration does not find a page it looks if an object exists that fits the name in the url. If so a new page is created by cloning the template and deliver this to the client. This way it would have been possible to have a huge amount of objects without the need to have a page for every object. Second it would have been possible to manage a single template that changes the content of all pages of a kind. I made this to let people design the page easily.
>
> But the approach is too complex and error prone. First I have a context object set in a pier structure that couples my model to the pier model. This is bad while exporting but also if pages are linked from within the site. It just doesn't work that good.
>
> I like the way you did it but there still open points:
>
> - creating a page is a one-time action. There is no way to alter the created pages afterwards in a systematical way. Do you think projects in bibliocello will need a system wide layout (or a layout for part of the page). What would be the way to adjust the layout of existing projects afterwards?
wouldn't necessarily be system-wide layouts. I would like each project
to have some level of control over the layout/look and feel ... there
would be defaults of course, but with pier the project owners should
be able to change and modify the way things are done for their
project ...
At least that's my thought process...
> - maybe I missed that piece of code but how do you create a pier page if the project is created from REST?
aware (you can access the Pier kernel from the model side), so I'm
imagining that the RESTful commands will call the Pier command ... I
have a RESTful create project URL, but it is not fully functional yet
(because of the missing Pier connection
>
> I think there a few ways to deal with that. Layout specific things could be handled by:
>
> - having system dependent stuff in the environment
> - embed other documents in the projects document. There was quite a nice way but I would need to research it again
> - have pages for e.g. projects share a single document. Don't know the problems here, yet
we haven't got too much invested in any particular approach ...
For me the tough thing to deal with for Pier has to do with the
"separate but equal" hierarchies for widgets and views ... I find that
I want to roll back and forth between a widget and a view and I
haven't found a happy medium where I can have a widget/view ...
perhaps my Pier fu is lacking...
Dale