Can you create a MetaValue object without an actual value?

[bytor99999]

MetaValueFactory.create() methods require that you supply a value. What if all you want is a MetaValue object that has no value in it yet. Basically an empty instance.

It would be nice to have a method like create(MetaType metaType) and it returns a MetaValue object of the correct type, that can be filled in later with a setValue()

Maybe I am just missing something, and that functionality is already there.

At this moment, I just know the MetaType.
I can, of course, go through the isXXX methods of MetaType and instantiate each Value object with "new" (Which is what I am going to do for now). But it would be cleaner in the MetaValueFactory object.

Thanks

[bytor99999]

Hmm, maybe the MetaValueFactory still needs it, but I think I see an issue in my code, that might make it unnecessary for me to have to have this.

[starksm64]

The TypeInfo api would have to be updated to support. I'm not sure its possible in general, maybe though.

[starksm64]

So the driving factor for this is the fact that the deployment templates can have ManagedPropertys that have no value. Either templates need include initial values for all properties (maybe not reasonable?), or we need to update the MetaType to support a createValue(TypeInfo), or allow a null in convertValue(Object value, TypeInfo type). What is most practical?

[adrian.brock]

A MetaValue without a value is just a MetaType.

I don't see why you need to create a MetaValue without a value,
you just need to have access to the MetaType in your template.

This is already the case for ManagedPropertys:

 /**
 * Get the type
 *
 * @return the type
 */
 MetaType getMetaType(); // Never null

 /**
 * Get the value
 *
 * @return the value
 */
 Object getValue(); // Could be null

[bytor99999]

I understand what you mean Adrian, and if I just had values already in hand to populate the MetaValue objects I would be golden. :)

The problem really occurs because of our code needs to adapt between complex MetaValue/MetaType objects and our ProperyMaps and PropertyLists objects.

I need to recurse level by level without knowing any specifics or having the entire structure of values in hand. I need to have the MetaValue object with the structure there so I can generally recurse through the complex object and create correct types within the structure. Then set values.

I have a long workaround that is currently working. However, having the ability to create an empty complex MetaValue object would save a lot of extra work.

Now, I think we can wait though on this and see how things work out, to see if the current code I have causes any issues.

Thanks Adrian

[adrian.brock]

"bytor99999" wrote:

I have a long workaround that is currently working. However, having the ability to create an empty complex MetaValue object would save a lot of extra work.

Yes, but you are trying to solve one problem by subverting another api.

I see this a lot at JBoss recently. It generally leads to hacking one bit
of the system to solve a problem that is elsewhere. But that hack
has knock on effects which leads to more hacks
until finally the whole thing collapses or becomes very ugly.

Fix the original problem rather than doing a quick fix..

In fact, back on topic, in the original OpenType framework, all values are immutable.
You effectively have to "clone" the whole structure to change it.

For the MetaType/Value we've allowed individual values to be mutable,
but it would be waste of memory to have to put an empty MetaValue everywhere
there is a null just so you know what type it is.

You should have the type (the class rather than the instance) somewhere else,
that's what the types are for, they're the meta description.

[bytor99999]

I completely agree with you Adrian, we shouldn't alter one api to fix someone else's problems.

My suggestion was to have a method in the MetaValueFactory object where you pass a MetaType and it returns a mutable MetaValue object. I was not suggesting putting empty MetaValues where ever you find nulls.

I thought maybe other people might want it to. I wouldn't go so far as saying that just because I would want that that everyone else must want it. I was definitely deferring that to you guys to determine. :)

There isn't a "Fix the original problem" in this situation.

Thanks

[starksm64]

The problem is not one of requiring ManagedPropertys to have mutable MetaValues, its knowing how to create a valid MetaValue from a MetaType. Having a MetaValue produced from a MetaType still requires casting to the correct concrete implementation to obtain the ability to set the value. At that point you still have to have a "valid" value, so I guess there is no magic other than having to know the various MetaTypes/MetaValues such that the existing MetaValueFctory.create(Object value) is sufficient.

[bytor99999]

Like, I said I have a workaround that is working. so no big deal. :)

[bytor99999]

Of course this came to me last night as I was just about to go to sleep.

Ok, what I mean here is just like in core Java Collections.

I can create a Map or List without putting any values into the collection, and I was hoping that that could also happen through the MetaValueFactory or even a constructor of say MapCompositeValueSupport.

Again this isn't a big deal, as instead of working top down to load the data, I have it working inside out.

[starksm64]

You can create a MapCompositeValueSupport without any values. You only specify the MetaType of the value in its ctor. Thereafter, you use it just like a map. What would you want to change?

[bytor99999]

Well, in that case, absolutely nothing. :) That is actually what I am using right now for the Map case.

Thanks