Marcos,

I'm looking now at the setup for zopeskel that makes the behavior you describe 
work.  It appears that the ability to take command-line arguments as preset 
values for template-based variables is actually a function of the zopeskel base 
template, rather than inherent in the paster command or template structure 
itself.  

Now, the reason that local commands don't allow the same thing is that the base 
class for local command templates inherits directly from 
paste.script.templates.Template, rather than from zopeskel.base.BaseTemplate 
(which adds the command-line behavior).  

At the moment I can see no reason that the base template for local commands 
shouldn't also inherit from the zopeskel.base.BaseTemplate.  I'd be open to 
seeing a branch that tried this out.  I'm thinking that if local command 
templates all inherited from the base zopeskel template class, they'd gain the 
ability to have preset configuration in the .zopskel file or provided on the 
command line when the addcontent command was run.  That would allow you to do 
what you describe below in your tests.  

Would you be willing to cut a branch for this and try it out?  I'm a bit 
swamped right now, or I'd do it myself.  I'd be happy to consult as you move 
forward.  

Also, could you open a ticket in the zopeskel tracker on plone.org for this 
'problem'?  

(http://plone.org/products/zopeskel/issues/)

As for anyone else out there on the list, can any of you think of a reason that 
local command templates should not inherit from the base zopeskel template 
rather than from the pastscript template class directly?  Can you think of 
anything Marcos should watch out for as he moves forward with this?

c

On May 3, 2010, at 5:47 AM, Marcos Romero wrote:

> Dear Cris
> 
> The command-line variables are taken only for commands like "create" but they 
> don't work for localcommands like "addcontent".
> 
> Cheers
> Marcos F. Romero
> Responsable de Desarrollo
> Inter-Cultura
> 
> marcos.rom...@inter-cultura.com
> www.inter-cultura.com
> +54 11 4542-8299
> 
> 
> On 03/05/2010 6:26, Marcos Romero wrote:
>> 
>> Hi Cris,
>> 
>> Yes, we have tried that. But we get a "You must provide no more than 2
>> arguments" (or something like that) error message.
>> An if we try with less arguments, the values aren't assigned to the proper 
>> vars.
>> 
>> Do you have any other suggestion?
>> 
>> Cheers and thanks for your prompt answer.
>> 
>> Marcos
>> 
>> On Mon, May 3, 2010 at 12:59 AM, Cristopher Ewing
>> <cew...@u.washington.edu> wrote:
>>   
>>> Marcos,
>>> 
>>> I believe that giving the --no-interactive switch to the paster command 
>>> indicates that all the arguments that you are wanting to pass to paster 
>>> will be present on the command line.  This means that you can provide 
>>> additional arguments to paster addcontent, like 'field_type=image'.  I 
>>> cannot remember off-hand the exact syntax for this, but I believe the 
>>> 'var_name=var_value' format will work.  Have you tried that?
>>> 
>>> c
>>> 
>>> On May 2, 2010, at 5:28 PM, Marcos Romero wrote:
>>> 
>>>     
>>>> Dear Cris:
>>>> 
>>>> After having finished the writing stage of our book (it's about to be
>>>> published!) we have now some time to tackle this delayed task.
>>>> We have the changes to the templates almost done, but we are facing a
>>>> problem while writing the tests.
>>>> We couldn't find any way to create a field, by means of atschema local
>>>> command, with a type other than "string" (the default one).
>>>> 
>>>> The problem with this is that, although we are confident with our
>>>> changes, we can't add a proper test.
>>>> 
>>>> What we would wanted to do is something like this:
>>>> 
>>>> paster addcontent atschema --no-interactive
>>>> 
>>>> but specifying field_type=image.
>>>> 
>>>> Do you have any advice for us?
>>>> 
>>>> Cheers
>>>> 
>>>> Marcos F. Romero and Juan Pablo Giménez
>>>> 
>>>> 2010/2/18 Marcos Romero <marcos.rom...@inter-cultura.com>:
>>>>       
>>>>> Cris,
>>>>> 
>>>>> Thanks a lot for your answer.
>>>>> 
>>>>> We will let you know about the fixes.
>>>>> 
>>>>> Cheers
>>>>> 
>>>>> Marcos F. Romero
>>>>> Responsable de Desarrollo
>>>>> Inter-Cultura
>>>>> 
>>>>> marcos.rom...@inter-cultura.com
>>>>> www.inter-cultura.com
>>>>> +54 11 4542-8299
>>>>> 
>>>>> Cristopher Ewing wrote:
>>>>> 
>>>>> Marcos,  Juan,
>>>>> You are, of course, correct in your reading of the situation.  The 
>>>>> consensus
>>>>> opinion seems to be that changing that back would be a good idea.  There 
>>>>> are
>>>>> alternative ways to get zope schema to work with AT objects, and those 
>>>>> ways
>>>>> can be documented.  Field properties with alternative names, for example.
>>>>>  These do not require that the Archetypes field use annotation storage at
>>>>> all.
>>>>> If you have code fixes for zopeskel, please feel free to submit them.  I
>>>>> would ask you to create a branch for your work, and contact me when you 
>>>>> are
>>>>> done.
>>>>> thanks for your input, and please let me know if there's anything else you
>>>>> want or need with respect to zopeskel.
>>>>> Cris
>>>>> On Feb 17, 2010, at 6:54 AM, Marcos Romero wrote:
>>>>> 
>>>>> Dear Cris:
>>>>> 
>>>>> Juan Pablo Giménez and I are working on a book that will be published 
>>>>> soon:
>>>>> http://www.packtpub.com/plone-3-3-products-development-cookbook/
>>>>> 
>>>>> We are in the revision stage and, after one Martin Aspeli's comment, we 
>>>>> spot
>>>>> the issue of changing the storage of title and description fields when 
>>>>> using
>>>>> "paster addcontent contenttype" command.
>>>>> When adding fields to the schema with "addcontent atschema" the new field
>>>>> also gets AnnotationStorage.
>>>>> 
>>>>> We also found this:
>>>>> http://n2.nabble.com/Should-ZopeSkel-stop-using-AnnotationStorage-td3420645.html
>>>>> 
>>>>> Do you know if there is any plan to change this? Is it in discussion? Do 
>>>>> you
>>>>> have this as an issue at all?
>>>>> 
>>>>> Do you want us to submit these changes?
>>>>> 
>>>>> Best regards
>>>>> --
>>>>> 
>>>>> Marcos F. Romero
>>>>> Responsable de Desarrollo
>>>>> Inter-Cultura
>>>>> 
>>>>> marcos.rom...@inter-cultura.com
>>>>> www.inter-cultura.com
>>>>> +54 11 4542-8299
>>>>> 
>>>>> ********************************
>>>>> Cris Ewing
>>>>> Webmaster, Lead Developer
>>>>> Department of Radiology Web Services
>>>>> University of Washington
>>>>> School of Medicine
>>>>> Work Phone: (206) 616-1288
>>>>> Cell Phone: (206) 708-9083
>>>>> Pager:      (206) 559-2306
>>>>> E-mail: cew...@u.washington.edu
>>>>> Web: http://www.rad.washington.edu
>>>>> *******************************
>>>>> 
>>>>>         
>>>> 
>>>> 
>>>> --
>>>> Marcos F. Romero
>>>> Responsable de Desarrollo
>>>> Inter-Cultura
>>>> 
>>>> marcos.rom...@inter-cultura.com
>>>> www.inter-cultura.com
>>>> +54 11 4542-8299
>>>>       
>>> ********************************
>>> Cris Ewing
>>> Webmaster, Lead Developer
>>> Department of Radiology Web Services
>>> University of Washington
>>> School of Medicine
>>> Work Phone: (206) 616-1288
>>> Cell Phone: (206) 708-9083
>>> E-mail: cew...@u.washington.edu
>>> Web: http://www.rad.washington.edu
>>> *******************************
>>> 
>>> 
>>>     
>> 
>> 
>>   

********************************
Cris Ewing
Webmaster, Lead Developer
Department of Radiology Web Services
University of Washington
School of Medicine
Work Phone: (206) 616-1288
Cell Phone: (206) 708-9083
E-mail: cew...@u.washington.edu
Web: http://www.rad.washington.edu
*******************************

_______________________________________________
ZopeSkel mailing list
ZopeSkel@lists.plone.org
http://lists.plone.org/mailman/listinfo/zopeskel

Reply via email to