project based pier
Locked
 
|
Hi,
I'm investigating using Pier to develop a site where registered users can have one or more associated projects. These projects should be bookmarkable. A good analogy would be the projects in squeaksource. Using that analogy how would one go about developing something like squeaksource in pier? Would the page structure expand as users registered new projects? For example:
root |--- home |--- users |--- projects | |--- Announcements |--- Gofer |--- Helvetica .
. |--- Pier | --- Wiki | --- Blog | --- News | --- Versions | --- Latest
where each of the projects includes it's own sub-pages; wiki/blog/news/versions/latest etc. As the number of projects grew, would using Pier like this cause any memory/performance issues? Any other thoughts for how to structure a site of this type.
Thanks Nick
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
Hi,
lets try to keep it as simple as possible, maybe you can just ask more questions if things are too simplistic. Doing SqueakSource in Pier, the simple way: - Each project would be a PRPage, with Wiki, Blog, News etc as children - For Blog you would use PierBlog - You implement a command (say, CreateProject, subclass of PRCommand) that adds a preconfigured set of pages (Wiki, Blog, News) to a project. - You restrict / modify the set of available commands inside a project page - You use PierUnixSecurity for users, access rights etc. - More specialized pages like Versions would perhaps be a custom subclass of PRStructure that displays itself in a special way (overriding renderContentOn:) Regarding memory / performance: I don't have real experience with this, but as long as everything fits in main memory you should be fine. Regarding persistence: you can use the Pier image-based persistency (some package in Lukas' monticello repository). That saves the whole image after executing commands (using a condition on the frequency of the saving, e.g,. at most every hour). If you are thinking about combining Pier with some other persistency mechanism (we've done Sandstone recently) things get more involved. In any case, I'd make a list of what going with Pier buys me in terms of saved development effort -- in comparison to doing it using basic seaside only. I guess that's what you're doing at the moment anyway ;-) HTH Matthias On Mon, Jan 18, 2010 at 12:43 PM, Nick Ager <[hidden email]> wrote: > Hi, > I'm investigating using Pier to develop a site where registered users can > have one or more associated projects. These projects should be bookmarkable. > A good analogy would be the projects in squeaksource. Using that analogy how > would one go about developing something like squeaksource in pier? Would the > page structure expand as users registered new projects? For example: > root > |--- home > |--- users > |--- projects > | > |--- Announcements > |--- Gofer > |--- Helvetica > . > . > |--- Pier > | --- Wiki > | --- Blog > | --- News > | --- Versions > | --- Latest > where each of the projects includes it's own sub-pages; > wiki/blog/news/versions/latest etc. > As the number of projects grew, would using Pier like this cause any > memory/performance issues? Any other thoughts for how to structure a site of > this type. > Thanks > Nick > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Nick
> I'm investigating using Pier to develop a site where registered users can
> have one or more associated projects. These projects should be bookmarkable. > A good analogy would be the projects in squeaksource. Using that analogy how > would one go about developing something like squeaksource in pier? Would the > page structure expand as users registered new projects? As I probably reported several times in the past, I've used Pier quite extensively for a software engineering course here at the university. At the beginning of the course the students register online at http://ese.unibe.ch (registration is now closed). They get subscribed to a mailing list and a page where they are the one one with access is created. They can use it as their "home-page". Later on in the course the students are put into groups and every group gets a sub-tree to manage their project. Some pages are public to everybody, some pages are visible or editable to certain student groups only, some pages are visible or editable by staff only, etc. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Thanks for the replies, they've clarified my thinking and helped me formulate my real question :-)
Continuing with squeaksource as an example, in a hypothetical simplified implementation it might use a model consisting of a collection of projects & users. Each project would contain a list of packages with each package having a list of package versions. With my limited knowledge of Pier a couple of implementations seem possible:
1) Create a Pier hierarchy of pages which mirror the model and potentially duplicate the data within it 2) Use the Pier page hierarchy as the model 3) Use the model to dynamically create Pier pages during a request.
As I see it there are problems with all three approaches: Solution (1) duplications data, with all the inherent issues around synchronising the two object hierarchies Solution (2) mixes model and view.
Solution (3) also mixes the model and view and would seem to subvert the intention and elegancy of Pier. Perhaps the solution is to mix Pier and a more 'traditional' seaside approach, where the view would reflect off the model when the data is well structured, and Pier components would be used in places where the content is more free-form. However this implementation would seem complex as the URL handling will be shared between Pier and 'traditional' seaside components. For example /projects/gofer/wiki/anotherpage would split the URL handling between the model handling the '/projects/gofer/wiki and Pier handling wiki/anotherpage. Also the data would potential reside in two places - the Pier kernel and the model - though my understanding of how pier persists it's data is still at the very early stages.
Hope this makes sense. Any thoughts? Nick
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
> 1) Create a Pier hierarchy of pages which mirror the model and potentially
> duplicate the data within it That's a limitation of the Pier structure hierarchy, it is a tree. Btw, the structure is the name for different kinds of pages, such as blogs, files, pages, components, etc. > 2) Use the Pier page hierarchy as the model You can do that. Pier internally models most of its things like that because they naturally fit into a tree. This is not a requirement though, you can easily have an independent model and reference it from your structures. > 3) Use the model to dynamically create Pier pages during a request. That could probably be done, but Pier is not really designed to support that. It would require some significant work on the Pier side I assume. > Solution (2) mixes model and view. I don't see why this mixes model and view? - Model: PRStructure and subclasses + some external code - Controller: PRCommand and subclasses + some external code - View: PRViewComponent and subclasses + some external code (Seaside mostly) In you case you would just add your own model classes to your own PRStructure subclasses that somehow interoperate with your model. Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Thanks for the clarification. If I've understood correctly, the best way to go is to subclass PRStructure for my model classes so that the model objects can be used directly by Pier, otherwise I'd end up having a duplicate Pier structure mirroring my model objects. The disadvantage of this is that the framework infects my classes; using Java terminology they are no longer POJOs [1], or have I missed something?
Would the combined approach, I attempted to outline in the previous message be overly complex to implement? I can image that splitting the url handling, and model between two structures could require lots of patching before they interoperate successfully.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
> Thanks for the clarification. If I've understood correctly, the best way to
> go is to subclass PRStructure for my model classes so that the model objects > can be used directly by Pier, otherwise I'd end up having a duplicate Pier > structure mirroring my model objects. The disadvantage of this is that the > framework infects my classes; using Java terminology they are no longer > POJOs [1], or have I missed something? PRStructure and subclasses is the model for the hierarchical structure of Pier. If your model is anything beyond the simple hierarchal folder and file structure of Pier, I wouldn't implement it as a subclass of PRStructure. For example, when you have the typical and highly interconnected University, Student, Professor, Course, Exam kind of model; I would implement all these classes separately from Pier. And then you have different structure subclasses that delegate to your complex domain model. So you'd probably had a - a university structure that would delegate to one University - a person structure, that would delegate to one Student or Professor - a course structure, that would delegate to one Course and the exams in that course Does that make sense? Another alternative is that you do not work with PRStructures at all, for example if you don't need the URLs. Then you can simply create your own model and your own plain Seaside app and embed it into Pier at some place (or use it independently from Pier). Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Nick
At 20:14 18/01/2010, Nick Ager wrote:
>1) Create a Pier hierarchy of pages which mirror the model and >potentially duplicate the data within it >2) Use the Pier page hierarchy as the model >3) Use the model to dynamically create Pier pages during a request. Hi Nick, I'm developing a system where Pier is successfully used following an approach which is close to (1), but there is no duplicated code/data, etc. ) To keep the analogy with MVC, I use Pier as View & Controller, but not as Model. The PRStructure hierarchy is used as an "organization" medium for parts of my business model that need visualization and user interaction. The latter are implemented by PRViewComponens (WAComponents). With your approach (2) there is indeed a risque of mixing model and view, but all depends on your application domain. As already stated by Lukas, if your business model elements "naturally fit into a tree", then it would probably be "natural" to adopt this approach. I won't recommend the 3rd approach since inconsistent with the design of Pier, and unnecessarily complicated. Hoping this helps, Regards, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Lukas Renggli
For example, when you have the typical and highly interconnected Thanks again for the help. I understand the delegate model, but I'm still concerned about the inherent duplication of the delegates mirroring the model objects.
In your example wouldn't there be collections of custom Pier structures so that there would be at least one Pier structure for each University, Student, course and exam, assuming that it was possible to use Pier to navigate to each of the model objects. Perhaps this is a non-issue, but I'd be concerned about keeping the delegates and delegees in sync.
Would combining the approaches work? The opening pages would use Pier to allow easy updating, however links to courses, students, exams etc would use procedural navigation code feeding off the model, and finally Pier could be used within the leaf nodes to allow courses, students etc to have wiki structured content. Ideally all bookmarkable, and the model would capture the wiki content created at the leaf nodes. Perhaps I'm making it more complicated then it needs to be?
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |