Prakhar Joshi
DA-IICT,Gandhinagar
On Sat, Mar 21, 2015 at 4:53 PM, Stephen J. Turnbull <step...@xemacs.org>
wrote:
> prakhar joshi writes:
>
> > So you want to store only changed attributes under a specific list
> > style in the table ? Isn't that make the table dynamic in width as
> > sometimes only one attribute is stored and sometimes 3-4 attributes
> > are stored ?
>
> That's a feature of object-relational managers (ORM) like SQLAlchemy.
> In the background there will be a special value in the backing RDBMS
> such as 'inherit' or perhaps NULL. But NULL is risky because it has
> assorted interpretations.
>
Yeah we will put values in the backing of RDBMS like the default values and
not NULL.
>
> > By extensibility you mean to add new attributes ?
>
> Attributes.
>
See we have a lot of attributes in mailing list table so admin can create
extra attribute other than those or admin will just play with the present
attributes in mailman3 mailinglist table. (I am considering the later one)
>
> > or add new class as there are few classes in the
> > mailman/src/mailma/styles/base.py (but that can't be possible
> > through web interface, I guess? )
>
> Anything's possible, but Zope's experience with that level of
> through-the-web extensibility was pretty bad. We don't need it.
>
> > > { name: <list specific>, read-only: no, notmetoo_default: no }
> > > { name: anonymous_overlay, read-only: yes, redact_all_addresses: yes }
> > > { name: discussion, read-only: yes, <usual discussion list options
> ...> }
> > >
> >
> > If there are more than 1 attributes in the last section of above list
> style
> > configuration then the list table will not have the same width ?
>
> I'm not sure what you're asking. Tables have to have the same width
> by definition. You use NULLs or other special values to simulate
> absence of a value, or a table join with optional attributes in a
> separate table. Object-oriented DBs can have different attributes for
> each object.
>
Yeah we will add other special values(like the default values) to simulate
the absence of a value in style table.
>
> > unspecified attributes ? You mean attributes other than that of mailing
> > list table ?
>
> No, I mean the attributes I was too lazy to write in the schematic
> example above.
>
> > I think we are still not on same page for list style storage as
> > still there are few things that I have in my mind like admin can't
> > create its own new attribute, he/she can just change the value of
> > the attribute, right ?
>
> Probably. What I had in mind was that site admins could add new
> Handlers that define attributes that aren't in the standard set, or
> somebody could want to import a style from a later version of Mailman
> that has such attributes.
>
See we have all the attributes in mailinglist table for list settings and
in the Handler we pick some set of attributes which are in mailing list
table and combine these attributes in a style name. right ? So that if
admin applied that style then the attributes set in that style will be
overwritten in the mailinglist table, Am I right ?
>
> > And if that is true(admin can't add new attributes) than how can we
> > just store only changed/modified attributes in the styles table as
> > than the table will not have same width, lets assume for style A we
> > will store one attributes and for style B we will store two/more
> > attribute.
>
> To create attributes on the fly is easy, even in RDBMS. You have a
> table user_defined_attributes with columns foreign_key, attribute_id,
> and attribute_value. Then do a select on the foreign key.
>
> > Basically the style table will be copy of mailing list table and
> > will have same number of column same as mailing list table with one
> > more column about permission (read_only or editable).
>
> You need to be more careful about this. I'm not sure exactly how this
> is implemented in Mailman 3, but a mailing list has attributes (such
> as the owner and the moderator list) that are not relevant to styles.
> There is going to be a question of whether to refactor the list schema
> into a "stylable" part and a "list-specific" part (so that the
> stylable part is literally a copy of the style) or to copy the
> individual attributes from styles to the list configuration.
>
In mailman3 the mailinglist table contains all the attribute so we will
copy only those attributes in the style table that are related to
styles(settings ) of the list only. Yeah I should have mentioned that
before.
Basically I was trying to store a style directly with its name, permission
and attributes like "reply to address","send welcome message" (Admin will
define values of these attributes and rest will have default values in the
style table) and when a style is applied to any list than these attributes
will be overwritten on the mailing list table from style table. This is the
way I was trying to store the style ( a very basic model for storing
styles) Now we will have the generic way to copy the attributes from a
particular style to the mailing list. I hope I am clear this time ?
I will explain my way of storing with an example. Lets assume we have a
mailing list named "XYZ" and it is stored in the mailing list table and as
we have all the attributes in mailing list table so some default values
will be set to all these attributes(as mentioned in
mailman/src/mailman/model/mailinglist.py) for the list "XYZ". Now if a
admin comes and create a style named "foo" so we will provide all the
attribute(by all attributes I mean the attributes in the mailinglist table
related to settings) to that admin with default values and now admin will
change few values and rest values will be as it is and admin hits the
submit button and provide an option of editable on that style(foo). Now
"foo" will be stored in the table with style name (foo), user_id,
permissions(editable) and all the attributes with their value set by that
admin.
Now if the admin applies this "foo" to a list("XYZ") then the values of
attributes from style table of "foo" will be overwritten in the mailing
list table of the list named "XYZ". So this way a style can be applied to a
list ("XYZ").
Now if other admin want to use that style("foo") he/she can also apply it
to their list (some other name, maybe "ABC") the other admin cannot edit
those style values as he/she is not the owner of that style. Style creators
can only edit their style and other admin can user them(if they wish).
This is what I am proposing for implementing the styles to the list. Here
admin can create new style, use them, edit them(only their styles), store
them and implement them to the mailing list.
Thanks,
_______________________________________________
Mailman-Developers mailing list
Mailman-Developers@python.org
https://mail.python.org/mailman/listinfo/mailman-developers
Mailman FAQ: http://wiki.list.org/x/AgA3
Searchable Archives:
http://www.mail-archive.com/mailman-developers%40python.org/
Unsubscribe:
https://mail.python.org/mailman/options/mailman-developers/archive%40jab.org
Security Policy: http://wiki.list.org/x/QIA9
