[Z3-sqlos] zope 2.x, Five and sqlos

[Peter Simmons]

Hi Brian,

Thanks that does the trick. That is actually fairly acceptable to me 
just requires documenting so that I know to use the exact factory name 
instead of just the Class name which is one thing that I tried.

I will probably implement some kind of MultiContainer

What is it that you don't like about it?

Cheers,
Pete

Brian Sutherland wrote:
> On Mon, May 08, 2006 at 07:04:19PM +1200, Peter Simmons wrote:
>   
>> Hi Brian,
>>
>> Ok sorry it was my dumb question about the /+/ view. I had tried to 
>> define the + view stuff again in my configure.zcml instead of just using 
>> the stuff defined for FiveSQLObjectContainer once I removed the stuff 
>> from my configure.zcml it works.
>>
>> Once I have some objects in the database should I be able to do 
>> something like
>>
>> container/id/edit.html to get it (like in Zope3)?
>>     
>
> Yep, that should work. But perhaps the exact value of id is throwing you
> off. You cannot choose the id, it will always be
> ${utility_id}.${sqlrow}.
>
> For example, in the functional tests there is a SamplePerson SQLObject
> registered in zcml like:
>
>   <sqlos:factory
>       id="sqlos.somename.SamplePerson"
>       component=".testing.sampleperson.SamplePerson"
>       description="A Sample Person"
>       />
>
> then to get the edit.html page of the first row of the database would be:
>
>     http://xx.yy/sample_person_container/sqlos.somename.SamplePerson.1/edit.html
>
> This is one of the reasons I don't like containers as we have them, but
> I'm still not sure how to make them better.
>
> Does that help?
>
>   
>> That doesn't work for me.
>>
>> Cheers,
>> Pete
>>
>> Brian Sutherland wrote:
>>     
>>> On Mon, May 08, 2006 at 03:36:48PM +1200, Peter Simmons (personal) wrote:
>>>   
>>>       
>>>> I have a container that extends FiveSQLOSContainer (forgive me if that 
>>>> name is slightly wrong) and I did a five:registerClass directive. The 
>>>> container type shows up on the ZMI add list (I would prefer plone's add 
>>>> list but this is actually ok for my use case) and I can add one. But 
>>>> then I can't call the /+/ view on it to add one of the SQLOS based objects.
>>>>     
>>>>         
>>> Hmm, this sounds like your container is not traversable in the Zope3
>>> way, or doesn't implement sqlos.interfaces.container.ISQLObjectContainer.
>>>
>>> Could you test if the configure.zcml in the FiveSQLOS product is being
>>> loaded? Perhaps by breaking the XML syntax of the file and trying to
>>> start Zope with debug mode on?
>>>
>>> What do the Zope logs have to say about your attempt to traverse to /+?
>>>
>>>   
>>>       
>>>> Any pointers, feel free to say I am trying in the wrong area, and/or 
>>>> ignore my idea and just tell me what you did if you like.
>>>>     
>>>>         
>>> Containers are probably the quickest way of getting a stepping stone
>>> from the ZODB to an RDB. But they do add an extra layer of complex code,
>>> so keep in mind that there are other ways as well.
>>>
>>> Depending on your use case, you might consider going one programmatic
>>> level down and just getting the IISQLObject utility and
>>> getting/operating on sqlobjects directly.
>>>
>>> Or you could create your own container. One FiveSQLOS user replaced his
>>> application object with a custom container that traverses like
>>> http://xx.yy/${utility_id}/${row_id}.
>>>
>>> Personally, I have tested running Zope3 without a ZODB and having a
>>> custom publication object. But the code was too fragile/unmaintainable
>>> to put in sqlos. Apparently http://launchpad.net runs this way with
>>> multiple ZDOB-less application servers using the same RDB.
>>>
>>>   
>>>       
>>>> Cheers,
>>>> Pete
>>>>
>>>> Brian Sutherland wrote:
>>>>     
>>>>         
>>>>> On Thu, May 04, 2006 at 01:46:25PM +1200, Peter Simmons wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> Hi Brian,
>>>>>>
>>>>>> Brian Sutherland wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> Great! Will you be at EuroPython by the way?
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> When/where is EuroPython,
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> In Geneva, about the beginning of July. So quite close.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>> I am based in Auckland, New Zealand so getting 
>>>>>> to Europe isn't usually straight forward. That said I really want to get 
>>>>>> to some Europe based sprints/conferences this year, to contribute back 
>>>>>> but also to meet people as I am planning to spend a year or two in/near 
>>>>>> Europe staring Feb/March 2007 and would like to still work with 
>>>>>> Zope/Plone python if possible.
>>>>>>
>>>>>> Its justifiable for our business here also and the learning 
>>>>>> opportunities are huge at these things if the ones I have gone to Oz for 
>>>>>> are anything to go by.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Exactly why I am going;)
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>>>>>> But in my experience for the initial 
>>>>>>>> situation you are usually best off if the configuration files get 
>>>>>>>> auto-generated some how from a design. Then they are transparent for the 
>>>>>>>> simple situation but available for when you get to a complex situation.
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>> I can't even begin to imagine how you would auto-generate ZCML;)
>>>>>>>
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>> I was thinking of generating python code + ZCML from say a UML diagram, 
>>>>>> like how you can with Poseidon + ArchGenXML for AT right now. Maybe it 
>>>>>> will become more clear to me but I don't quite see why we couldn't 
>>>>>> generate an initial set of stuff and then be able to edit it afterwards. 
>>>>>> ArchGenXML is very well done in this way but suffers from being built on 
>>>>>> AT so if you get complex situations you kinda hit a wall and your code 
>>>>>> gets ugly. Its close but just needs the separation that component 
>>>>>> architecture provides as the MixIn strategy gets in the way.
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> Ah that sounds much more reasonable, might even be something I would
>>>>> want to use.
>>>>>
>>>>>   
>>>>>       
>>>>>           
>>>   
>>>       
>
>