On 4 October 2012 18:46, Burak Arslan <[email protected]> wrote:
> On 04/10/12 16:56, Stefan Andersson wrote:
>>
>> On 4 October 2012 17:27, Burak Arslan <[email protected]> wrote:
>>>
>>> On 04/10/12 14:13, Stefan Andersson wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have fault type now with support for other subelements both in
>>>> respons and wsdl, but now when I synced up with your master repo I get
>>>> circular import problem because of changes in model/complex.py, my new
>>>> fault.py imports ComplexModelMeta and now complex.py imports stuff
>>>> from primitive and primitive imports fault.
>>>>
>>>> The way I see around this is to implement a copy of ComplexModelMeta
>>>> in fault or try break it out from complex.py without any dependencies
>>>> on complex.py, what would you prefer?
>>>
>>>
>>> Can you show me your work so far? Why did you need ComplexModel machinery
>>> in
>>> Fault?
>>
>> I have commited it to the branch restriction (commit:
>>
>> https://github.com/norox/spyne/commit/6878512695aa3db1ffbcfdc12c90c740072bfdce)
>
>
>
> Hi,
>
> First, why not base on ComplexModelBase if your metaclass is
> ComplexModelBaseMeta?
I ran into some problem with the first prototype that I made this way,
but that can probably be fixed without changing to much in complex
model.
>
> Common sense says that _base -> primitive -> complex -> fault is a plausible
> dependency graph and the thing that is actually out of place here is
> primitive importing fault.
>
> So "the right thing" to do here is to move the {to,from}_string logic to
> ProtocolBase to avoid primitive importing fault.
Don't you mean ModelBase?
I can give it a go, hopefully soon, just a little pressed on time for
some other projects right now.
>
> If that'd be too much work for you,
>
> _base -> primitive -> complex
> \-> fault
>
> also sort of makes sense (this is currently the case without your patch),
> but you'd have to re-implement a ComplexModelMetaLite as moving some of the
> code in complex.py to another module won't break the circle.
>
> This is a hack and I would not really prefer this solution. I also don't
> think it'd be less time-consuming because the spyne.mode.complex module is
> quite mature as it covers a lot of corner cases that took a while to run
> into.
>
> So all things considered, I think you should follow the first option.
>
> Best,
> Burak
>
>
>>
>>>
>>>> //Stefan
>>>>
>>>> On 2 October 2012 12:56, Stefan Andersson <[email protected]> wrote:
>>>>>
>>>>> Ok, I will take look and see how much work it is, would make
>>>>> integration with some system we have easier.
>>>>>
>>>>> On 2 October 2012 10:54, Burak Arslan <[email protected]> wrote:
>>>>>>
>>>>>> On 02/10/12 09:48, Stefan Andersson wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Do you know if anyone have been looking into adding other subelements
>>>>>>> to SOAP Faults?
>>>>>>> According to
>>>>>>> http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383507
>>>>>>> it's supported, "Other Fault subelements MAY be present, provided
>>>>>>> they
>>>>>>> are namespace-qualified" (in the end of 4.4 right before 4.4.1).
>>>>>>
>>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> No, and I had no idea it was allowed (must have missed that line).
>>>>>>
>>>>>> Burak
>>>
>>>
>
_______________________________________________
Soap mailing list
[email protected]
http://mail.python.org/mailman/listinfo/soap
