Hi David,
We here at the Pier-Magritte mailing list are always eager to help out =)
You have an interesting plug-in in the works, so that makes it worth it too,
On Wed, Jul 15, 2009 at 12:18 AM, Dennis Schetinin <chaetal(a)gmail.com>wrote;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
--
http://jmck.seasidehosting.st