El ago 7, 2013 3:51 a.m., "Richard Schwarting" <aquarichy gmail com> escribió:
>
> Hi Daniel.
>
> Thanks again for the work. So, I haven't compiled and run your code in the serialization branch, but after reading it, I have some questions, to help me better understand what your goal is.
>
> *** DomNode.vala
> - is there any reason that you're defaulting _str to "DomNode" for to_string ()?
> - in theory, it gets built anew each time. (In fact, I'm not sure whether we need the _str field anymore.)
>
Nop. I don't remember to change it. I agree to remove _str too.
But I start to think that Node must be an interface with virtual methods as default implementation.
> *** Element.vala
> - any particular reason you're changing from set_content to
> add_content when we're setting the content of an Element?
>
Yes. set_content deletes my added nodes and replace them with the text set and that's I want to avoid. I think we need to add a method to replace content or set text in a node in order to replace its nodes with text or just add text with no child nodes remove.
> *** NodeList.vala
> - NodeListIterator.advance () should not need to explicitly call
> .is_empty () because the calling code, GenericNodeListIterator, does
> that itself. NodeListIterator.advance has protected visibility, so
> nothing outside will be calling it either.
>
You're right. I forget to remove it when I try to fix a crash. If change it just need to test against my branch and unit tests I want to add.
> *** Serializable.vala
>
> The interface for Serializable was modelled off of ebassi's
> serializable interface for JSON. The names of the interface methods
> and their signatures are intended to resemble those in GObject and
> GObjectClass.
>
> I notice that you've explicitly changed the names of some methods, and seemed to move some class methods of Serialization into Serializable methods. Any particular reason why?
>
Yes. Setting names to GObjectClass seems to me unclear about it purposes, but the main reason is because I added the possibility to skip properties to be serializable and then is just get properties.
serializable branch tries to implement .Net's Xml.Serializer while keeps your actual implementation unchanged, may be by adding a new class or new properties to Serialization class to use one method or other. For now just Serializable is implemented, when Unit Tests are fixed I've continue on Serialization class and merge both methods.
> I'm going to read through the logic now and see what motivates all the new methods.
>
My objective is to have .Net equivalent functionality into GXml, to port one of my projects to Vala. If you want to see your self I can share you some XML files and you can download OpenSclConfigurator[1] app witch uses OpenScl library to de/serialize XML files to class objects, through .Net Xml.Serializer class.
[1] sourceforge.net/projects/ opensclconfigurator
> Cheerio,
> Richard Schwarting
>
>
> On Tue, Aug 6, 2013 at 5:31 PM, Richard Schwarting <aquarichy gmail com> wrote:
>>
>> I'll probably have to get back to you with tomorrow on comments on your branch. Sorry.
>>
>>
>> On Tue, Aug 6, 2013 at 4:58 PM, Richard Schwarting <aquarichy gmail com> wrote:
>>>
>>> I finally pushed the change to serialization to gsoc2013 that fixes it. The main change (breaking API) is that instead of gxml_serialization_serialize_object () returning a GXmlNode (which was the document_element of a document) it now returns a GXmlDocument (and its document_element is what you used to get). Consequently, gxml_serialization_deserialize_object () now takes a GXmlDocument, which incidentally cleans up the API usage slightly (you don't have to read a document and then pass doc.document_element; instead just pass the doc!).
>>>
>>> I've requested a mailing list:
>>> https://bugzilla.gnome.org/show_bug.cgi?id=705571
>>>
>>> Let me know about the invalid UTF-8 strings. I think they were related to the case where the memory was already freed before the serialize_object () method returned the GXmlNode.
>>>
>>> I'll look into parallel installation. My current plan for releasing is:
>>> 0.3.2: all the non-API changes pushed here, so people who are using 0.3.x can keep doing it with the fixes.
>>> 0.4: most of the API breaking things, of which there are a few more coming (all classes are going to reflect their corresponding names from the W3 DOM spec; it's silly that I let them vary to begin with).
>>>
>>> Regarding IRC, right now I lurk in #gtk+ and #vala, so if you just want to talk to me, you can find me there. We can create an impromptu #gxml one for now if you like, or we can formally do it.
>>>
>>> I'm going to review and comment on your serialization finally.
>>>
>>> Sorry for the delay, GUADEC is busy, and so is my Masters, so I've had a hard time being as responsive as I should be.
>>>
>>> Cheerio,
>>> Richard Schwarting
>>>
>>>
>>>
>>> On Mon, Aug 5, 2013 at 4:14 AM, Daniel Espinosa <esodan gmail com> wrote:
>>>>
>>>> Great!
>>>>
>>>> I'm not too much on irc. But I could if you consider benefit.
>>>>
>>>> What is the channel we can join?
>>>>
>>>> Really thanks for your advise. For now I think gxml serializable is almost ready, but really considering to use TextReader/Writer for serialization because memory use, or add an interface to implement it, I've created a branch locally for this witch I can share i you want, but at the end, are you planning to release shortly a 0.4, if so my plans on TextReader/Writer must wait.
>>>>
>>>> I'm planning to provide gxml parallel features with C# Serializer, I have a project on sourceforge called OpenSCLConfigurator using that tech but I want to rewrite it using Vala.
>>>>
>>>> El ago 4, 2013 8:45 p.m., "Richard Schwarting" <aquarichy gmail com> escribió:
>>>>
>>>>> Just to keep you up to date, hacking resumes tomorrow (the last day of talks at GUADEC ended today). My primary goals are this, reviewing Adam Ples' patch in Bugzilla, and preparing releases.
>>>>>
>>>>> Are you on IRC much?
>>>>>
>>>>>
>>>>> On Wed, Jul 31, 2013 at 2:16 PM, Daniel Espinosa <esodan gmail com> wrote:
>>>>>>
>>>>>> Great! Thanks.
>>>>>>
>>>>>> I'm waiting for it in order to merge again and add my own test cases to serializable and fix Serialization to handle two ways: the actual one in 0.3 and the new one in up coming 0.4
>>>>>>
>>>>>> By the way, I think we need to add 0.4 sufix to .pc, Gir, subdirectories and others, in GXml in order to allow parallel installation with 0.3 series.
>>>>>>
>>>>>> One example is Gda.
>>>>>>
>>>>>> https://git.gnome.org/browse/libgda/tree/libgda/Makefile.am
>>>>>>
>>>>>> As far I can see you have all infrastructure to make the change.
>>>>>>
>>>>>> An for last, are there a gxml mailing list? To make this discussion public?
>>>>>>
>>>>>> El jul 31, 2013 12:29 a.m., "Richard Schwarting" <aquarichy gmail com> escribió:
>>>>>>
>>>>>>> Oh, I can fix that. I'll do that once I arrive at GUADEC. Thanks for the heads up.
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Jul 30, 2013 at 6:59 PM, Daniel Espinosa <esodan gmail com> wrote:
>>>>>>>>
>>>>>>>> Just to know if I need to file a bug.
>>>>>>>>
>>>>>>>> gsoc2013 branch, witch I've synced with my serialize branch, fails to run make check command.
>>>>>>>>
>>>>>>>> My problem is at /gxml/serialization/xml_serialize
>>>>>>>>
>>>>>>>> fruit_xml.to_string () returns invalid UTF8 strings, but it is not consistent, some rare cases just get in an infinity loop, others messages like;
>>>>>>>>
>>>>>>>> output error : string is not in UTF-8
>>>>>>>>
>>>>>>>> Some times empty strings.
>>>>>>>>
>>>>>>>> Are your make check command works for you?
>>>>>>>>
>>>>>>>> --
>>>>>>>> Trabajar, la mejor arma para tu superación
>>>>>>>> "de grano en grano, se hace la arena" (R) (en trámite, pero para los cuates: LIBRE)
>>>>>>>
>>>>>>>
>>>>>
>>>
>>
>