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....
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.
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:
> 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....
> 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.
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
On Sep 13, 5:55 pm, Alexutz <alex.id.ciob...@gmail.com> wrote:
> 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....
> > 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.
> 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
> On Sep 13, 5:55 pm, Alexutz <alex.id.ciob...@gmail.com> wrote:
> > 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....
> > > 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.
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.
On 5 oct., 03:19, Yonas <yonask...@gmail.com> wrote:
> On Sep 19, 2:28 pm, Yonas <yonask...@gmail.com> wrote:
> > 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
> > On Sep 13, 5:55 pm, Alexutz <alex.id.ciob...@gmail.com> wrote:
> > > 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....
> > > > 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.
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.
On Oct 7, 6:57 am, Alexutz <alex.id.ciob...@gmail.com> wrote:
> 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.
> On 5 oct., 03:19, Yonas <yonask...@gmail.com> wrote:
> > How's the new version going?
> > On Sep 19, 2:28 pm, Yonas <yonask...@gmail.com> wrote:
> > > 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
> > > > 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.
> > > > > 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....
> > > > > 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.
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.
On 21 oct., 01:27, Yonas <yonask...@gmail.com> wrote:
> 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.
> On Oct 7, 6:57 am, Alexutz <alex.id.ciob...@gmail.com> wrote:
> > 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.
> > On 5 oct., 03:19, Yonas <yonask...@gmail.com> wrote:
> > > > 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
> > > > > 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{
> > > > > 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.
> > > > > > 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....
> > > > > > 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.
> 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.
> On 21 oct., 01:27, Yonas <yonask...@gmail.com> wrote:
> > 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.
> > On Oct 7, 6:57 am, Alexutz <alex.id.ciob...@gmail.com> wrote:
> > > 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.
> > > On 5 oct., 03:19, Yonas <yonask...@gmail.com> wrote:
> > > > > 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
> > > > > > 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{
> > > > > > 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.
> > > > > > > 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....
> > > > > > > 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.
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-...
