Developers of Sympa

[Olivier Salaun - CRU <address@concealed>]

Hi Mark,

Mark Valiukas a écrit :

> > This parameter would be defined as follows in the %List::pinfo hash 
> > (title_id entries are incorrect) :
>
> Thank you for this, it's great. I'm really beginning to appreciate how 
> well sympa seems to have been designed for extensibility. 

Extensibility is one of our our main concern in Sympa design 
(authorization scenarios, templates, hierachical directories, separated 
roles, configuration file definition,...). The %List::pinfo hash fully 
defines all list parameters in the same way an XML Schema would.

> I've set 'group' => 'categorisation' here, and have added links to it 
> in admin_menu.tpl and  edit_list_request.tpl as I think this should be 
> accessed as an item under "Edit List Config" unless you can suggest a 
> better location.    I'm having a little problem though. 

We're trying to keep the number of categories as low as possible and 
therefore I'd suggest you use the existing 'sending' category that 
corresponds to the "Sending/Reception" web admin category.

> > 'keywords' =>{'format' => '[^,]+', # Everything BUT a ','
> >              'occurrence' => '1-n',
>
> Okay, this will save multiple 'keywords' items.
> This is causing me a little grief - the multiple instances of 'keywords'.
>
> edit_list_request.tpl doesn't handle 'keywords' occurring more than 
> once - when set to occur once, it displays and saves okay. When set to 
> occur one or more times, the keywords field shows as something like " 
> ARRAY(0x8ff816c)" (which is not that surprising as we're trying to 
> view an array as a scalar, I guess, and thus see where it is rather 
> than what it contains).
> [...]
> However, I don't believe this is entirely satisfactory - the entry and 
> display of a comma-delimited list is what we were discussing, rather 
> than individual keyword items inside a category. I think a 
> comma-delimited field for entry and display would be appropriate, as 
> it allows several items to be entered at once and a whole lot to be 
> replaced in one action. Correct me if I'm wrong, but I don't think 
> there's anything in sympa at present that requires the handling or 
> display of a comma delimited list. As far as I can tell, this would 
> require some extra code to determine how the form fields being passed 
> back are to be handled and take appropriate action with them (feed 
> them directly, or split then feed)

You're right Sympa, as it stands, does not handle correctly the 
'keywords' I suggested. Sympa can cope with comma-delimited multiple 
fields (have a look at 'available_user_options' parameter definition) 
but it Sympa can't handle it if the paragraph itself has a '0-n' 
occurence ;  'category' has a multiple occurence.

> An alternative approach - which requires no recoding of 
> edit_list_request.tpl - is to just use a single keywords field
> for each category. This would involve setting "'occurrence' => '1'" 
> for keywords, and splitting individual keywords off in whatever code 
> uses them. I think it would be better to have the keyword items as 
> individual elements in the hash though. I'll play with this a little 
> more this afternoon; I'm sure there's something I'm just not seeing. 

I think that should be fine for a start ; we could later extend it to 
allow multiple keywords. This extention requires some work on 
edit_list_request.tpl template but essentialy in the 
&wwsympa::do_edit_list() subroutine.

--
Olivier Salaun
Comite Reseau des Universites