Re: [Mailman-Developers] GSOC'15: Improving styles for lists
Prakhar Joshi
DA-IICT,Gandhinagar
On Sat, Mar 21, 2015 at 9:03 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
Abhilash Raj writes:
Admin can change there values.
You meant 'their' here and not 'there'.
(-: Lighten up on the spelling stuff. *I* make that typo regularly
(I think I mostly manage to correct it before posting, I hope :-).
You're right about reviewing the language, though. I had no idea what
Prakhar (@prakhar126: is that your preferred form of address?) was
talking about. Thanks for the translation!
Prakhar is fine. yeah prakhar126 is my email address.
I will have table for style which will be having only changed
attributes in it and rest of the attributes will be null.
I'm not a fan of this API using nulls. I would prefer a special value
of inherit or defer to indicate that omission of a value is
deliberate. (This can be hidden from end users.)
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 ?
It's possible that None (or NULL in the backing store) is an
appropriate way to implement inherit, but only if concrete styles
(that is, styles that are actually part of a mailing list) have all
attributes required. I don't see how this is possible if we want to
allow for extensibility by users.
By extensibility you mean to add new attributes ? 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? )
For example if admin has changed the attribute
send_welcome_message under discussion and other attribute like
advertise under public list then these two attributes with
their values defined by admin will be stores under the list style
name and rest all the attributes which have been there in the
mailinglist table will be null for the list style table. Now by
using apply function on list style table the values of attributes
will be overwritten on the mailing list table when admin apply
that list.
I don't understand when apply happens. I'm guessing that the
proposal is to have a stack of styles in the configuration UI:
{ 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 ?
where unspecified attributes are inherit, and when the admin is
done, they hit an apply button, which searches the stack from top down
and takes the first non-inherit value found. The constructed
configuration is validated for all required options being set.
Finally, the list configuration is instantiated in the list table.
unspecified attributes ? You mean attributes other than that of mailing
list table ?
Only admin will be able to change the settings and by having user
section I mean we have to specify the admin of each style so that
at time of showing present styles for a particular admin we will
fetch only styles with that admin name from the style table, as
we don't want other (admins) to change saved styles for
particular admin. That is why admin field is essential in the
style table.
Lists may have multiple admins AFAIK. I think the list field I
propose above is a better construct.
Yeah that read only and editable thing will be better and no need to add
user_id for each list style.
If we create styles for ease-of-implementation of Admins and Moderators,
it is required that we support some level of authorization to edit/use
those styles. So for that purpose each style create would belong to a
`User` and can only be viewed/edited by him. Ideally it would be nice if
we could set different access levels for styles, like public, read_only,
private.
I thought about this for a few minutes, and I think we need a concrete
schema and some use cases. For example, I don't see why styles would
need to be private. And although I used read-only myself, I just
meant writing not authorized. One could also simply have all styles
be read only once registered (unused locally-defined styles could be
garbage-collected or explicitly deleted).
yeah that's the main objective.
This is not the association of users with styles, it is just
meant for authorization purpose.
Sure, users are always about authorization in this kind of
application. My point is that there are too many kinds of user in
the mailing list context, and that in Mailman 3, ordinary subscribers
are included when we talk about user in the sense used in the code.
Here by user I mean admins and I will take care of it in future to be
specific.
I think we are still not
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
Prakhar Joshi DA-IICT,Gandhinagar On Sat, Mar 21, 2015 at 9:10 PM, Stephen J. Turnbull step...@xemacs.org wrote: I think we're pretty much in agreement on most things. Please update your proposal on melange to reflect this discussion. (The quoting has gotten too fragmented to be very useful in understanding what progress has been made.) Okay Will include all the key points discussed here in the proposal and will update it on milange . 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
I think we're pretty much in agreement on most things. Please update your proposal on melange to reflect this discussion. (The quoting has gotten too fragmented to be very useful in understanding what progress has been made.) ___ 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
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.
By extensibility you mean to add new attributes ?
Attributes.
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.
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.
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.
___
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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
Hi Prakhar, I see that you mentioned below the details of our conversation, but the language looks confusing to me. Please look out for simple mistakes in your English before sending the mail, not just here but anywhere. On Friday 20 March 2015 12:37 PM, prakhar joshi wrote: hi, For the storage of list we will have table for list styles and when the admin creates a new list he/she will edit some attributes of particular list. By attribute I mean the options under each mailing list style like announce list have allow list post. Admin can change there values. You meant 'their' here and not 'there'. style table will have all the attributes(same attributes that are listed in mailing list table) in column but the values of attributes that user will change will be stored in the table and rest values will be null. With improving the apply method for styles we can over write the present settings of the mailing list. I hope this is making sense to you ? What he means to say is we can create a generic Style class, another implementation of IStyle interface which instead of having static values of attributes like existing styles would have methods to dynamically fetch the stored styles from database. This new class would have all the attributes of a MailigList class that can be customized using list styles ( we can leave out attributes like list_name, list_id). I will have table for style which will be having only changed attributes in it and rest of the attributes will be null. For example if admin has changed the attribute send_welcome_message under discussion and other attribute like advertise under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list. Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table. If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a `User` and can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private. prakhar joshi writes: what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it. Who are these users (subscribers? admins?) and why do you want to associate styles with users? Please use more descriptive terms unless you really need to describe something generic. But here IIRC the styles are for lists, and therefore the relevant users are list admins. However, why would a style be associated with a list admin? The same admin might have announce lists and discussion lists as well as anonymous lists, and so on. This is not the association of users with styles, it is just meant for authorization purpose. Also `user_id` would be better option to use as a ForeignKey instead of `user_name` which is an optional argument for `User`. -- thanks, Abhilash signature.asc Description: OpenPGP digital signature ___ 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
hi Abhilash, Thanks for all these corrections. Prakhar Joshi DA-IICT,Gandhinagar On Fri, Mar 20, 2015 at 7:03 PM, Abhilash Raj raj.abhila...@gmail.com wrote: Hi Prakhar, I see that you mentioned below the details of our conversation, but the language looks confusing to me. Please look out for simple mistakes in your English before sending the mail, not just here but anywhere. I will definitely take care of it in future. On Friday 20 March 2015 12:37 PM, prakhar joshi wrote: hi, For the storage of list we will have table for list styles and when the admin creates a new list he/she will edit some attributes of particular list. By attribute I mean the options under each mailing list style like announce list have allow list post. Admin can change there values. You meant 'their' here and not 'there'. Yes. style table will have all the attributes(same attributes that are listed in mailing list table) in column but the values of attributes that user will change will be stored in the table and rest values will be null. With improving the apply method for styles we can over write the present settings of the mailing list. I hope this is making sense to you ? What he means to say is we can create a generic Style class, another implementation of IStyle interface which instead of having static values of attributes like existing styles would have methods to dynamically fetch the stored styles from database. This new class would have all the attributes of a MailigList class that can be customized using list styles ( we can leave out attributes like list_name, list_id). yeah, that is what I want to say. I will have table for style which will be having only changed attributes in it and rest of the attributes will be null. For example if admin has changed the attribute send_welcome_message under discussion and other attribute like advertise under public list then these two attributes with their values defined by admin will be stores under the list style name and rest all the attributes which have been there in the mailinglist table will be null for the list style table. Now by using apply function on list style table the values of attributes will be overwritten on the mailing list table when admin apply that list. Only admin will be able to change the settings and by having user section I mean we have to specify the admin of each style so that at time of showing present styles for a particular admin we will fetch only styles with that admin name from the style table, as we don't want other (admins) to change saved styles for particular admin. That is why admin field is essential in the style table. If we create styles for ease-of-implementation of Admins and Moderators, it is required that we support some level of authorization to edit/use those styles. So for that purpose each style create would belong to a `User` and can only be viewed/edited by him. Ideally it would be nice if we could set different access levels for styles, like public, read_only, private. Yeah we can provide option these options to admin. prakhar joshi writes: what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it. Who are these users (subscribers? admins?) and why do you want to associate styles with users? Please use more descriptive terms unless you really need to describe something generic. But here IIRC the styles are for lists, and therefore the relevant users are list admins. However, why would a style be associated with a list admin? The same admin might have announce lists and discussion lists as well as anonymous lists, and so on. This is not the association of users with styles, it is just meant for authorization purpose. Also `user_id` would be better option to use as a ForeignKey instead of `user_name` which is an optional argument for `User`. Yeah, basically we need to relate each style with its owner so user_id will be more appropriate. -- thanks, Abhilash ___ 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
On Mar 19, 2015, at 03:31 PM, Stephen J. Turnbull wrote: Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I've always thought that styles should be compositional for exactly the reasons you describe. Mailing lists have a weird amalgam of attributes, inherited and flattened from the MM2.1 mixin strategy. Cheers, -Barry ___ 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
[Mailman-Developers] GSOC'15: Improving styles for lists
prakhar joshi writes: I am thinking of storing the styles in the database by creating a table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal. ___ 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
hi, so we should have templates already created in a folder with default values of the attributes in it. the templates will be of BASIC OPERATION, BOUNCES etc. and under each of the template we will gonna have attributes for it and then we can apply these templates on the list and even user can edit these templates, right ? One thing how these templates will be stored for the user is still a doubt for me ? Can you please help me with that ? Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 19, 2015 at 12:01 PM, Stephen J. Turnbull step...@xemacs.org wrote: prakhar joshi writes: I am thinking of storing the styles in the database by creating a table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal. ___ 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it. I think the attributes for the classes defined already will be fixed? So now if we feel the requirement of including new things to style (like an additional class in that file ) Then we will add new table for that also. And now the flow will be like.. the mailing list table will be same as right now. And each of the new table we will get the attributes filled by the admin. So the list styles will be stored in that way. And we have user name also so only that user will get the styles which are created by him/her. Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 19, 2015 at 1:40 PM, prakhar joshi prakhar...@gmail.com wrote: hi, so we should have templates already created in a folder with default values of the attributes in it. the templates will be of BASIC OPERATION, BOUNCES etc. and under each of the template we will gonna have attributes for it and then we can apply these templates on the list and even user can edit these templates, right ? One thing how these templates will be stored for the user is still a doubt for me ? Can you please help me with that ? Thanks, Prakhar Joshi DA-IICT,Gandhinagar On Thu, Mar 19, 2015 at 12:01 PM, Stephen J. Turnbull step...@xemacs.org wrote: prakhar joshi writes: I am thinking of storing the styles in the database by creating a table for the styles in the db Mailman's databases are not relational dbs, they're object-oriented. Underneath the objects are stored in relational dbs and managed by an ORM (SQLAlchemy), of course, but the Mailman API is object-based. If you want to think of your schema in terms of tables, I don't think you'll have any trouble in design, but when you get to the implementation stage you'll have to shift gears to OODB style. and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I think this is probably not the best way to go. Some of the attributes change over time, some attributes flip back and forth, and so on. Some lists may have a unique combination not very useful for other lists/list owners. So I think a library of templates so that you can set many attributes at once by applying a template is a better way to go. Also, I suspect it would be useful to allow very incomplete templates so that you could apply template A to get the basic character, then apply template B (which is very incomplete and only changes two attributes) to get the effect you want. I haven't thought about it carefully, so don't just assume everything I wrote is right. Maybe it will be useful for refining your proposal. ___ 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
Re: [Mailman-Developers] GSOC'15: Improving styles for lists
prakhar joshi writes: what if we create separate tables for each class in the mailman/src/mailman/styles/base.py and store the name and their attributes in it with user_name with it. Who are these users (subscribers? admins?) and why do you want to associate styles with users? Please use more descriptive terms unless you really need to describe something generic. But here IIRC the styles are for lists, and therefore the relevant users are list admins. However, why would a style be associated with a list admin? The same admin might have announce lists and discussion lists as well as anonymous lists, and so on. ___ 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
[Mailman-Developers] GSOC'15: Improving styles for lists
hi, I am thinking of storing the styles in the database by creating a table for the styles in the db and this table will contain all the attributes of a style and these entries can be null too. So a table which will contain a style name with all its attributes. Now as we have table for mailing list containing all the attributes in the mailing list table. So now the style table will contain all these attributes and in the mailing list table we will just store the mailing list name and the style name and this way we can connect the two table by providing foreign key of style_id to the mailing list table? I really need to discuss that thing with you people as I am new to this organization so I have very little experience with mailman core. Thanks, Prakhar Joshi DA-IICT,Gandhinagar ___ 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
