Hi, In your case, you probably do not need to store text (this is what gets in the #text port) but the string correspondent. Just use "text asString" before you store the updated text in your object.
Cheers, Doru On Wed, Sep 17, 2014 at 9:02 PM, Offray Vladimir Luna Cárdenas < off...@riseup.net> wrote: > Hi Sven, > > > On 09/17/2014 01:30 PM, Sven Van Caekenberghe wrote: > >> Offray, >> >> On 17 Sep 2014, at 18:50, Offray Vladimir Luna Cárdenas < >> off...@riseup.net> wrote: >> >> Hi, >>> >>> Finally, with help in the Moose mailing list (thanks Doru!), I have >>> automatic update of nodes in my outliner, and its working pretty well. >>> >> >> It is good that you are making progress. >> >> > Thanks, and thanks too for your quick answer. > > I'm using STON for persistence and I see that when I update a node body >>> content I got a lot of metadata on the text like runs, text font, text >>> color, lastIndex, lastOfset. For reference I have attached two files, >>> test.1.ston which is the original outline with no updates on nodes and >>> test.2.ston which contains the updated nodes with metadata. >>> >> >> 0. The goal of STON is to produce a faithful, textual, somewhat readable, >> representation of an object graph (with object sharing and circular >> references) that can be read to recreate the same object. JSON was the >> starting point, the inspiration, but JSON is too limited to implement the >> stated goal. >> >> So my questions are: >>> >>> 1. There is any way to exclude the text metadata or to select the >>> "deepness" of the exportation, including just the content of the text, but >>> not the metadata of it? >>> >> >> You can override/reimplement #toSton: and #fromSton: (check the other >> implementors) to customize how your objects are handled. >> >> Looking at your example, I don't really see the problem, you used Text >> instances, so they are serialized as such. This way, potential styling is >> preserved. >> >> > Yes, there is no problem and preserving text styling is a good think. I > was just curious. > > 2. I see that there is a way to export from STON to JSON. There are >>> plans to implement something like YAML[1] export? If not, which would be a >>> good approach to explore the existing code on STON-Core and implement this? >>> >> >> No, that is not a goal/objective at all, there is no framework for that. >> The JSON thing is a hack 'because it could be done', it cannot support the >> stated goal. >> >> 3. I have seen that text string containing a carriage return are stored >>> with "\r" character in them, there is any way to make the text be stored >>> containing actual carriage returns? >>> >> >> STONWriter will escape all dangerous characters by default and this is >> not optional (right now). You are however free to use those characters in >> strings, it should work as expected with STONReader. >> >> From your earlier questions I infer that you want to turn STON in some >> kind of literal programming language. This is quite far from the original >> goal. You are of course free to use STON as inspiration or building block. >> >> > My idea is to create some kind of Open/Garage/Citizen Science Notebook for > interactive documentation and visualization combining Pharo/Roassal/Moose > and I want to use STON or YAML for storing and sharing that notebooks. The > inspiration comes from tools like Leo Editor[1] and IPython Notebook[2] and > Freemind/Docear[3] and some other ideas that I have not seeing elsewhere > (yet ;-)). > > [1] http://leoeditor.com/ > [2] http://ipython.org/notebook.html > [3] https://www.docear.org/ > > Despite of times when I can not advance as fast as I would like or > understand things better, is has been quite a pleasure working with Pharo > communities and tools. > > Thanks again, > > Offray > > > > -- www.tudorgirba.com "Every thing has its own flow"
