On Wed, Jul 15, 2009 at 12:18 AM, Dennis Schetinin
<chaetal@gmail.com> wrote:
I found I was wrong with my plans. So I need more help, if you still don't mind. So, what I want. I want to join several Polls (from the respective package) in a Questionnaire.
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
User should see several polls with options, select one answer in each of them, and submit his votes with one click on 'submit' button.
I don't know how to implement it with the current design of Polls. I neither know how to use several Vote commands in one form nor see any other ways to do what I want (not reimplementing this in whole). What is (Pier+Magritte-)correct way to do that?
--
Dennis Schetinin
_______________________________________________
Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki