Embedding view

It sounds like you want functionality like that of the postticker  wrt a blog.

When i wrote a PRCase subclass, I referred extensively to the PBBlog and its associated classes for direction.

John

So, (Pier-)widget implementation is the correct way?

Thank you, John and Lukas

This is what I had in mind when i suggested the postticker type of arrangement.

I will lay out the steps for how I see the design. I have no idea how much you have accomplished, how astute you are with regards to Pier design. I am certainly no expert but have a good grasp of it, so I am giving the soup to nuts version and then hopefully it will help otheres as well. Maybe it will be good enough (and correct enough!) to be included in a tutorial somewhere. Keep in mind that you want to start as simple as possible. The Blog is a good example but appears daunting because it has some very complex view requirements. Most PRCases probably dont need that much in the way of view rendering.
And for editing of the Pier structures, Pier does most of it automatically.

My design would use a PollManager (PRCase) to manage the "package" of available Poll questions (akin to the blog as a manager of posts). You definitely want to look at its Model class for guidance. That is what I am referring to as i write this :)

There really is not much more to PBBlog than:

1) It descends from PRCase
2) It implements a few choice methods:
   a) On the class side #canBeParentOf: aClass is implemented to tell Pier what the Add command can add to it (what will show up in the drop down box when the Add command is invoked)
   b) isAbstract is implemented to return false.
   c) On the instance side, #viewComponentClass
   d) As a general usage pattern, #allXxxxIn: aContext will enumerate all the children (Polls)
   e) #isValidView: aComponentClass in: aContext might be needed  (though I have gotten away without this one...)
3) It implements Magritte descriptions of the various instance variables. Any setting or items that can be edited at runtime send #beSetting or #beEditable to the description (This is what makes these fields show up when you click Edit Settings or Edit respectively).

I really do not see many settings for this piece of the design except maybe how many questions to feed to connected Questionnaire widgets, max life for a Poll question to be considered for the widget feed etc. You decide. Then give them setting descriptions.
The view component will me minimal. This is what is used to render the manager when we click on a link to it, of which the only one should be in the Commands section when we the admin, log in to add a Poll or two or change a settting. This view is not for general consumption. So all it renders is itself and the Poll questions.

Polls would also be a subclass of PRCase and do most of what PollManager does except it will also implement #canBeChildOf: aClass to return true only if aClass = PollManager. Again all of the settings and calculated fields get Magritte descriptions so they show up in the automatically generated editor. Some of these settings will be the fields on which our widget will filter which Polls it displays.
The view component will render the question in some form, maybe just the question text and the total vote statistics. Also a link to itself for easy navigation (instead of making us go down into the Commands section and trying to find it in the tree of structures) . Again the main thing here is that it is just rendering for our view only. The widget will be the public renderer of the Poll.

(If we would be happy with the one structure being the renderer of our poll, ie making our poll manager viewable by the public but only show some selection of questions we COULD buiild that functionality into the PollManager's view component class and be done with it. All that logic would be designed into the rendering code. But that would make it less flexible.)


We want the more flexible Questionnaire widget set up. My design is going to be alot like the PBPostticker widget so lets take a closer look at what that does.  Notice that almost all of its mehtods involve rendering as it is a Seaside component. It has a blog method that get the blog for which it 'ticks' via a description. It gets the posts that it will display from the blog. Out widget will do the same thing, It will have a description for the PollManager and a way to get all the Polls it will display. Again, any Magritte described fields will be editable by the site admin. #descriptionBlog is very instructive. It tells us how to describe the PollManager (we should implement a #isPollManager method to return true so our description can return the poll manager(s) available to be chosen as the Poll source. If we want to filter polls on some field of the polls then we need a description for that. It might be complex since we want a dynamic selection of what those field values are. This logic is up to you. The rest is the rendering code that displays the Poll question to whomever wanders into our site, the choices of answers and what happens when the user clicks one and when they click the submit button. This component definitely requires the most work.

I hope you fiind this instructive. If anyone finds any glaring errors please feel free to correct me.
John
 

It's  a nice manual. But unfortunately I didn't find solutions for the problems I met. Perhaps it's because I didn't explain what I want correctly. Let me try again...

Eep! I hadn't seen those 8) heheh ahem  That you were using an existing package was a bit of info missing from your original post.....

This is all Lukas and Phillipe's fault so I must defer to them :)

I also notice that I cannot make the Vote command visible to non-logged in users by using the ChangeOther command. Can someone shed some light on that?