> Den 09.07.2011 15:25, skrev Greg Brown:
>> It is theoretically possible to serialize a component hierarchy into BXML.
>> The challenge would be handling includes, script, and define blocks, which
>> are not intrinsically part of the UI. These elements would need to be
>> attached to their asso
Den 09.07.2011 15:25, skrev Greg Brown:
It is theoretically possible to serialize a component hierarchy into BXML. The
challenge would be handling includes, script, and define blocks, which are not
intrinsically part of the UI. These elements would need to be attached to their
associated objec
It is theoretically possible to serialize a component hierarchy into BXML. The
challenge would be handling includes, script, and define blocks, which are not
intrinsically part of the UI. These elements would need to be attached to their
associated objects somehow so that BXMLSerializer#writeObj
Den 09.07.2011 14:13, skrev Greg Brown:
OK, thanks for clarifying. I hadn't really considered it before, but I think I
agree that serialization should be reciprocal. And yes, it does seem like
mutating the input stream would violate that reciprocity (though, at the
moment, BXMLSerializer does
OK, thanks for clarifying. I hadn't really considered it before, but I think I
agree that serialization should be reciprocal. And yes, it does seem like
mutating the input stream would violate that reciprocity (though, at the
moment, BXMLSerializer does not support writeObject(), so it is sort o
Makes sense to me. The skunk branch is a perfect place for such prototyping.
On Jul 9, 2011, at 6:06 AM, Noel Grandin wrote:
> I'm liking the level of discussion going on here - it shows that we have
> people with passion in this project, which is awesome.
>
> A while ago we used to have branche
Den 08.07.2011 21:28, skrev Greg Brown:
Den 08.07.2011 21:04, skrev Greg Brown:
Sorry, I wasn't clear either. :-) I should have asked "what do you mean by
'it'"? In other words, what do you think breaks the contract defined by Serializer?
That's what I tried to say with this sentence:
"If
I'm liking the level of discussion going on here - it shows that we have
people with passion in this project, which is awesome.
A while ago we used to have branches in the repo for each committer, where
that committer could push prototypes and proposed changes - discussions are
a lot easier when t
> Den 08.07.2011 21:04, skrev Greg Brown:
>> Sorry, I wasn't clear either. :-) I should have asked "what do you mean by
>> 'it'"? In other words, what do you think breaks the contract defined by
>> Serializer?
>
> That's what I tried to say with this sentence:
>
> "If you write an object you
Den 08.07.2011 21:04, skrev Greg Brown:
Sorry, I wasn't clear either. :-) I should have asked "what do you mean by
'it'"? In other words, what do you think breaks the contract defined by Serializer?
That's what I tried to say with this sentence:
"If you write an object you expect to get the
OK. Thanks for clarifying. Carry on. :-)
On Jul 8, 2011, at 3:02 PM, Chris Bartlett wrote:
> Greg,
>
> Understood, and I think we are in general agreement, but things have
> gone off topic a little.
>
> Hopefully you understand I am not proposing to fork anything merely
> for the sake of it.
Sorry, I wasn't clear either. :-) I should have asked "what do you mean by
'it'"? In other words, what do you think breaks the contract defined by
Serializer?
On Jul 8, 2011, at 2:56 PM, SYSE | Edvin wrote:
>
>
> Den 08.07.2011 19:38, skrev Greg Brown:
>>> It atleast breaks with BXMLSeriali
Greg,
Understood, and I think we are in general agreement, but things have
gone off topic a little.
Hopefully you understand I am not proposing to fork anything merely
for the sake of it. Any decision to a fork would only come about
after the collaboration process 'rejected' the proposal, but wh
Den 08.07.2011 19:38, skrev Greg Brown:
It atleast breaks with BXMLSerializer, but one could argue it breaks with
Serializer as well
Can you clarify what you mean by "breaks" here?
I mean "breaks the contract of", or "goes outside the scope of" the
original intent. Sorry for the bad langu
By the way, I don't mean to be preachy - I'm just saying that, if you think you
have a good idea, then put it out there and let it get tossed around a bit.
From my experience, that's the best way to reach a solution that everyone is
happy with.
On Jul 8, 2011, at 2:14 PM, Greg Brown wrote:
> W
What I'm trying to say is that, even though collaboration may be difficult at
times, it generally produces a better result than the efforts of multiple
individuals working independently. Just because I may not agree with all
aspects of a change you propose (or vice versa) does not mean that I do
> If a feature is not wanted by the 'main' project, but might be useful
> to others, then forking and making it public provides the feature to
> others who might be interested
If a proposed feature is truly useful to others, then I'd say that it should be
considered for inclusion in the main pro
> It atleast breaks with BXMLSerializer, but one could argue it breaks with
> Serializer as well
Can you clarify what you mean by "breaks" here?
On 8 July 2011 23:34, Greg Brown wrote:
>> I think this kind of forking could be a healthy way to add "exotic" features
>> that might skew the perception of that the Serializer interface encapsulates.
>
> ...snip...
> IMO forking in any capacity is not "healthy". It only serves to fragment the
>
Den 08.07.2011 19:00, skrev Greg Brown:
"that the Serializer interface encapsulates." -> "what the Serializer interface
encapsulates."
As you stated earlier, the Serializer is not supposed to perform
transformations and such, just create object instances based on the source.
Chris's suggesti
> "that the Serializer interface encapsulates." -> "what the Serializer
> interface encapsulates."
>
> As you stated earlier, the Serializer is not supposed to perform
> transformations and such, just create object instances based on the source.
> Chris's suggestions might go beyond what the Se
Den 08.07.2011 18:34, skrev Greg Brown:
I would just use my custom version of BXMLSerializer to process all
BXML files whether they are official '.bxml' files or '.ebxml'
If the BXML file doesn't contain any 'Transformable' objects, then it
will behave in exactly the same way as the official BXML
>> I would just use my custom version of BXMLSerializer to process all
>> BXML files whether they are official '.bxml' files or '.ebxml'
>> If the BXML file doesn't contain any 'Transformable' objects, then it
>> will behave in exactly the same way as the official BXMLSerializer.
>
> I think this
Den 08.07.2011 17:25, skrev Chris Bartlett:
Yes, 100%.If it turns out to be as useful to me as my 15 min
prototype suggested, I will start to use it, and will be happy to
share it via an Apache Extras project or similar.
I would just use my custom version of BXMLSerializer to process all
B
(Switched from the 'org.apache.pivot.util.MessageBus' thread to avoid
taking it off topic)
On 8 July 2011 22:04, SYSE | Edvin wrote:
> As for BXMLSerializer, it looks like it is used mainly in demos/tutorials,
> some skin/internal stuff etc, but quite frankly - couldn't you just fork
> BXMLSeria
I just mean that if project A includes some source derived from
project B, but does not maintain any dependency on project B, then
project B can do whatever it wants with no impact on project A.
On 8 July 2011 21:05, Greg Brown wrote:
> I must be misunderstanding what you mean by "standalone". Do
I must be misunderstanding what you mean by "standalone". Do you mean an
application that is tied to a specific version of the Pivot platform? If so,
then yes, you are correct - but that obviously has other disadvantages.
On Jul 8, 2011, at 10:00 AM, Chris Bartlett wrote:
>>> Any changes in the
>> Any changes in the original source tree wouldn't stop a
>> standalone forked project from functioning
>
> Not true. Changes in a future release could easily break the forked code.
'standalone'
> Of course it is forking. I thought that was too obvious to bother stating.
>
> I feel that the 'opening the door to future incompatibility' bit was
> melodramatic.
It was not meant to be. Forking is something that is generally discouraged at
the ASF. It goes against the collaborative nature
Greg,
Thanks for taking the time to reply.
I will definitely look into the possibilities offered by
newTypedObject(). If it can help me achieve some of my goals, I will
be happy.
I don't see any point in us trying to change the other's opinions, so
I'll leave things as they are - with the excep
> - Instantiating a final class with no public no-arg constructor
> (UnfriendlyPOJO example)
> - Instantiating an immutable object (essentially the same as above)
> - Instantiating objects via a 'Builder' style pattern (similar to the above)
> - Retrieving objects via a factory (similar to previous
Greg,
I have been away from my desk for the last 2 days, so apologies for
the delay, but this is the first chance I have had to reply.
Firstly, I want to clarify that my desire for functionality is the
driver here, and that I have no special attachment to the specifics of
the proposal. Any other
> You mention concerns, but do you see any value in i? Whether in my
> examples or in other areas?
If the same thing can be accomplished via existing means (which, based on your
examples, seems possible), then I don't personally see a strong case for it.
> The fact that it is a small, backwardl
Greg,
My replies are inline.
You mention concerns, but do you see any value in i? Whether in my
examples or in other areas?
The fact that it is a small, backwardly compatible change (unless I
have missed something major) which offers many new possibilities and
alternatives is the big selling poi
Sandro made the same completely valid point.
This was just another example of one of the many possibilities that
this simple change would allow. It is certainly not a suggestion that
the Pivot project should perform such a task.
I was trying to demonstrate how a small change would permit 'custom
Hi Chris,
That's an extensive proposal. You have obviously put a lot of thought into it.
I'd have some concerns about the complexity and overall approach, though. I
have tried to capture these in my comments below.
> Example 1 - User defined, simplified API for creating object graphs
>
>
>
>
> This proposal also opens the possibility of
> internationalizing/translating bean class and property/styles names
> via simple alias classes. Styles can be exposed as bean properties to
> simplify things even further as demonstrated below.
An interesting idea, but it could cause quite a bit of
On 4 July 2011 19:41, Sandro Martini wrote:
>>Yes, it could certainly lead to some weird BXML files that are written
>>in multiple 'human languages', but right now it is possible to use
>>BXMLSerializer to create graphs of objects that have 'non-English'
>>class names.
>
> Ok, for me you can try a
we have to see what others
say.
But in any case you'd have to publish in another place, please consider one
of our apache-extras projects ... so a custom class could be a good idea, at
least now.
Bye
--
View this message in context:
http://apache-pivot-developers.417237.n3.nabble.com/Idea-for-a-useful-change-to-BXMLSerializer-tp3133361p3137431.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
On 4 July 2011 17:13, Sandro Martini wrote:
> I'd prefer something like Command, but usually I've seen that the Command
> pattern returns void in its execute method
Good point. I suppose it could be BXMLCommand?
I also thought about Action as a name, but that clashes with
org.apache.pivot.wtk.Acti
nit automated tests could go
under Tools (or better, "Developer Tools" subproject).
Note, if you want to prototype something, tell me for grants under our
apache-extras projects ... or otherwise for prototypes with direct impact on
Pivot core projects a better place could be the /skunk area .
I wasn't aware of Felxjson, but Metawidget and similar projects were
certainly an inspiration for the dynamic GUI / object CRUD stuff.
I'm sure many more possibilities will become apparent as the idea is
applied to different problem domains.
On 4 July 2011 11:55, Superstring Media wrote:
> Some
A 'BXMLExpander' tool is another possibility. It would take an input
BXML file, process each Transformable, expand it into BXML, and then
output to a new file.
For those of you familiar with the fantastic Project Lombok, this
would be equivalent to the 'delombok' tool.
http://projectlombok.org/
h
Some of the applications of your idea seem to be inclusive of functions in
other APIs like Flexjson's Transformers or Metawidget's dynamic UIs.
All really great applications coming from a single enhancement, sounds
excellent indeed.
http://flexjson.sourceforge.net
http://metawidget.org
Thom
O
Another thing that popped into my mind...
This proposal also opens the possibility of
internationalizing/translating bean class and property/styles names
via simple alias classes. Styles can be exposed as bean properties to
simplify things even further as demonstrated below.
The following exampl
Better naming options might be
public interface Command {
public Collection execute();
}
or
public interface Function {
public Collection execute();
}
On 3 July 2011 04:36, Chris Bartlett wrote:
> public interface Transformable {
> public Collection transform();
> }
Thanks for the encouragement, Sandro.
I couldn't decide if this is a really useful proposal, or something
that sounds good but might not be of much value in the real world.
Anyway, we can wait to see what others have to say.
Chris
On 3 July 2011 16:42, Sandro Martini wrote:
> Hi Chris, I think
Hi Chris, I think this idea is great, and could solve/simplify so many
cases that I'd like to have it in 2.1 . I don't know if it will be better to
put some transformable examples in the wiki, or under skunk, or under one of
our apache-extras projects, but it' a detail. Let's wait to see what othe
Firstly, my apologies for the length of this email (and if there are
lots of typos). It might be easier to just jump to the example BXML
fragments which demonstrate possibilities of the proposed change, and
then skip back to the more wordy stuff.
I will post some proof of concept code in the morn
49 matches
Mail list logo
