Next on FlexXB
13 views
Skip to first unread message
Alexutz
Sep 11, 2010, 7:22:42 AM9/11/10
to FxWorks
Hello,
It's been a while since the release of 1.6.2 and, after a well
deserved vacation, the time has come to look to what the future brings
to FlexXB. I'm curently working on v1.7 which will bring some highly
anticipated features...
The first one will be circular reference handling, such as JaxB
provides; take a look here for more detais:
https://jaxb.dev.java.net/guide/Mapping_cyclic_references_to_XML.html.
This is a big one and I hope I'll get it right in a reasonable amount
of time :D.
A variant on this feature would be the ability to be able to only
specify the id of a reference in your class, like this post explains:
http://groups.google.ro/group/flexxb/browse_thread/thread/14630a80cd87db24?hl=ro.
FlexXB 1.7 will allow for more ways of notifying objects of various
processing steps (preserialize, predeserialize, postserialize,
postdeserialize). The regular, event based system will still be
available, in addition you will be able to implement some interfaces
that will make your methods get calles when specific events happen,
rather than going through the regular method.
I'm also planning a refactoring of the way FLexXB is linked with a
model object cache. These two entities are too higly coupled and there
is no way to, for example, say "I don't want caching" or "I want a
cache provider that does things diferently". In 1.7 the two entities
will be less coupled and you will be able to opt for a no cache
approach or use existing cache providers or even write your own. This
is a pretty powerful feature as it paves the way for many interesting
means of caching the objects.
As always, some fixes wil be included, and I'm talking now about an
issue with default namespaces, when you get some aaa prefixed
namespaces in xml children (http://code.google.com/p/flexxb/issues/
detail?id=29) . I'll probably release a 1.6.3 version with this fix
only because I can see how problematic this bug can become especially
when you need to comply to namespacing rules. I'll see about that in
the next few days and will let you know.
I guess that's all for now. If you have comments or suggestions or
proposals for new features I'll be happy to hear them.
Have a good one,
Alex
It's been a while since the release of 1.6.2 and, after a well
deserved vacation, the time has come to look to what the future brings
to FlexXB. I'm curently working on v1.7 which will bring some highly
anticipated features...
The first one will be circular reference handling, such as JaxB
provides; take a look here for more detais:
https://jaxb.dev.java.net/guide/Mapping_cyclic_references_to_XML.html.
This is a big one and I hope I'll get it right in a reasonable amount
of time :D.
A variant on this feature would be the ability to be able to only
specify the id of a reference in your class, like this post explains:
http://groups.google.ro/group/flexxb/browse_thread/thread/14630a80cd87db24?hl=ro.
FlexXB 1.7 will allow for more ways of notifying objects of various
processing steps (preserialize, predeserialize, postserialize,
postdeserialize). The regular, event based system will still be
available, in addition you will be able to implement some interfaces
that will make your methods get calles when specific events happen,
rather than going through the regular method.
I'm also planning a refactoring of the way FLexXB is linked with a
model object cache. These two entities are too higly coupled and there
is no way to, for example, say "I don't want caching" or "I want a
cache provider that does things diferently". In 1.7 the two entities
will be less coupled and you will be able to opt for a no cache
approach or use existing cache providers or even write your own. This
is a pretty powerful feature as it paves the way for many interesting
means of caching the objects.
As always, some fixes wil be included, and I'm talking now about an
issue with default namespaces, when you get some aaa prefixed
namespaces in xml children (http://code.google.com/p/flexxb/issues/
detail?id=29) . I'll probably release a 1.6.3 version with this fix
only because I can see how problematic this bug can become especially
when you need to comply to namespacing rules. I'll see about that in
the next few days and will let you know.
I guess that's all for now. If you have comments or suggestions or
proposals for new features I'll be happy to hear them.
Have a good one,
Alex
Alexutz
Sep 13, 2010, 3:55:38 AM9/13/10
to FxWorks
Just though of this... for some time in the future..
We know that during a project's development sometime the xml sent back
and forth changes and you end up with different version for expressing
the same thing. Also, your UI may talk with different versions of
servers which need different ways of expressing that data. It would be
nice to have FlexXB involved into this, by specifying versions of the
xml. Basically, a class, or a field in a class, may be annotated with
multiple FlexXB metadata to express it under various versions; FlexXB
would then provide a way for you to easily switch between versions and
let it do all the work for you.
I'm envisioning something like:
//This is the second version of the xml structure (need to pass the
version identifier to FlexXB)
[XmlClass(name="V2Test", version="v2")]
//This is the default xml specification (automatically picked up by
FlexXB)
[XmlClass(name="Test")]
public class Test{
[XmlElement(alias="v2TestField", version="v2")]
[XmlAttribute(alias="testField")]
public var field1 : String
}
You would call FlexXB engine by:
var test : Test = new Test();
var xml : XML = FlexXBEngine.instance.serialize(test, "v2");
var copy : Test = FlexXBEngine.instance.deserialize(xml, false, "v2");
to make it parse the xml under the new version. Passing nothing as
version identifier will make FlexXB process the object the regular
way.
What do you think?
Alex
On 11 sep., 14:22, Alexutz <alex.id.ciob...@gmail.com> wrote:
> Hello,
>
> It's been a while since the release of 1.6.2 and, after a well
> deserved vacation, the time has come to look to what the future brings
> to FlexXB. I'm curently working on v1.7 which will bring some highly
> anticipated features...
> The first one will be circular reference handling, such as JaxB
> provides; take a look here for more detais:https://jaxb.dev.java.net/guide/Mapping_cyclic_references_to_XML.html.
> This is a big one and I hope I'll get it right in a reasonable amount
> of time :D.
> A variant on this feature would be the ability to be able to only
> specify the id of a reference in your class, like this post explains:http://groups.google.ro/group/flexxb/browse_thread/thread/14630a80cd8....
We know that during a project's development sometime the xml sent back
and forth changes and you end up with different version for expressing
the same thing. Also, your UI may talk with different versions of
servers which need different ways of expressing that data. It would be
nice to have FlexXB involved into this, by specifying versions of the
xml. Basically, a class, or a field in a class, may be annotated with
multiple FlexXB metadata to express it under various versions; FlexXB
would then provide a way for you to easily switch between versions and
let it do all the work for you.
I'm envisioning something like:
//This is the second version of the xml structure (need to pass the
version identifier to FlexXB)
[XmlClass(name="V2Test", version="v2")]
//This is the default xml specification (automatically picked up by
FlexXB)
[XmlClass(name="Test")]
public class Test{
[XmlElement(alias="v2TestField", version="v2")]
[XmlAttribute(alias="testField")]
public var field1 : String
}
You would call FlexXB engine by:
var test : Test = new Test();
var xml : XML = FlexXBEngine.instance.serialize(test, "v2");
var copy : Test = FlexXBEngine.instance.deserialize(xml, false, "v2");
to make it parse the xml under the new version. Passing nothing as
version identifier will make FlexXB process the object the regular
way.
What do you think?
Alex
On 11 sep., 14:22, Alexutz <alex.id.ciob...@gmail.com> wrote:
> Hello,
>
> It's been a while since the release of 1.6.2 and, after a well
> deserved vacation, the time has come to look to what the future brings
> to FlexXB. I'm curently working on v1.7 which will bring some highly
> anticipated features...
> The first one will be circular reference handling, such as JaxB
> provides; take a look here for more detais:https://jaxb.dev.java.net/guide/Mapping_cyclic_references_to_XML.html.
> This is a big one and I hope I'll get it right in a reasonable amount
> of time :D.
> A variant on this feature would be the ability to be able to only
Yonas
Sep 18, 2010, 11:28:43 PM9/18/10
to FxWorks
That's a great idea! (about the versions) We've needed this in a
couple of projects and had to handle our own de/serialization instead
of using FlexXB in these instances
couple of projects and had to handle our own de/serialization instead
of using FlexXB in these instances
Yonas
Oct 4, 2010, 8:19:25 PM10/4/10
to FxWorks
How's the new version going?
Alexutz
Oct 6, 2010, 3:57:20 PM10/6/10
to FxWorks
Sorry for answering with such a delay. Been busy working on the new
version. I'm planning to release it sometime around the 22nd of
October. Notification system and new object cache done, circular
reference handling in the making and I hope I'll have time to add the
versioning. Makes me wonder if I should make it v2.0 directly seeing
how many changes I'm planning to add :D.
> > > > Alex- Ascundeţi textul citat -
>
> - Afişare text în citat -
version. I'm planning to release it sometime around the 22nd of
October. Notification system and new object cache done, circular
reference handling in the making and I hope I'll have time to add the
versioning. Makes me wonder if I should make it v2.0 directly seeing
how many changes I'm planning to add :D.
>
> - Afişare text în citat -
Yonas
Oct 20, 2010, 6:27:59 PM10/20/10
to FxWorks
Hey Alex.
I know your in the middle of developing versioning now. I don't know
if you've done it already but it would be cool to have the version
number come from the actual xml when deserialsing, so it could
automatically pick which version to use. There could be a
versionAttribute or versionElement property of the XmlClass tag which
defined which xml attribute or element which contained the xml
version. That would mean the server could send you different versions
and flexXB would automatically choose the tags to deserialise it with.
Maybe there's a neater way of doing it rather than having two extra
properties though
You might have done this already, but just a suggestion.
> > > > > Alex- Ascundeþi textul citat -
>
> > - Afiºare text în citat -
>
>
I know your in the middle of developing versioning now. I don't know
if you've done it already but it would be cool to have the version
number come from the actual xml when deserialsing, so it could
automatically pick which version to use. There could be a
versionAttribute or versionElement property of the XmlClass tag which
defined which xml attribute or element which contained the xml
version. That would mean the server could send you different versions
and flexXB would automatically choose the tags to deserialise it with.
Maybe there's a neater way of doing it rather than having two extra
properties though
You might have done this already, but just a suggestion.
>
> > - Afiºare text în citat -
>
>
Alexutz
Oct 25, 2010, 5:34:55 AM10/25/10
to FxWorks
Good idea with the version location. Unfortunately I have no time to
do it in 1.7. I'll postpone it to the 1.7.1 version which should be
out in a week or so.
> > > - Afiºare text în citat -- Ascundeţi textul citat -
do it in 1.7. I'll postpone it to the 1.7.1 version which should be
out in a week or so.
Alexutz
Nov 30, 2010, 9:34:53 AM11/30/10
to FxWorks
Kinda late for anouncing but the version location stuff is in 1.7.1 :D
> > - Afişare text în citat -- Ascundeţi textul citat -
Alexutz
Dec 1, 2010, 2:14:27 PM12/1/10
to FxWorks
A follow up concearning FlexXB future developments. This will probably
be an ongoing thread. The main plan is about making FlexXB support
multiple serialization formats in a pluggable manner. Check out
details about this on my blog: http://www.alexandru-ciobanu.ro/2010/12/01/thoughts-on-the-future-of-flexxb/
Alex.
be an ongoing thread. The main plan is about making FlexXB support
multiple serialization formats in a pluggable manner. Check out
details about this on my blog: http://www.alexandru-ciobanu.ro/2010/12/01/thoughts-on-the-future-of-flexxb/
Alex.
Reply all
Reply to author
Forward
0 new messages