Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I think you can use <a href="http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/utils/package.html#describeType%28%29" rel="nofollow">describeType</a> to introspect objects. I would probably take a very different approach, though. </p> <p>Create an interface, something like IObjectIWantToCreatePropertyWindowFor and have your relevant shape objects implement this. The interface could somehow define the list of properties you want edtiable on the object. I might even make this an array of Value Objects that contain the property name, a display name, and the type of editor it should have. Each object can hard code this list of properties in it.</p> <p>The property window could be written to redraw itself based on the interface values. Most likely I'd do that using a List class with an <a href="http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/spark/components/SkinnableDataContainer.html#itemRendererFunction" rel="nofollow">itemRendererfunction</a> somehow.</p> <p>What you want to do doesn't sound hard, but it's not trivial either. </p> <hr> <p>Nooga asked a more detailed explanation. This is all psuedo code, but:</p> <p>1) Create an interface:</p> <pre><code>package com.propertyInspector { public interface IPropertyInspectable { function get inspectableProperties( ):array; } } </code></pre> <p>2) Create a class that implements IPropertyInspectable</p> <pre><code>package com.propertyInspector { public class myClass implements IPropertyInspectable { public var property1 :String public var property2 : Int public function get inspectableProperties():Array{ return [{name:'property1',type:'String'},{name:'property2',type:'String'}, ] } } } </code></pre> <p>3) Create your property inspector.</p> <pre><code>&lt;s:List dataProvider="{someSelectedObjectThatImplementsIPropertyInspectable.inspectableProperties}"&gt; &lt;s:itemRenderer&gt; &lt;s:Label text="data.name"/&gt;&lt;s:TextInput /&gt; &lt;/s:itemRenderer&gt; &lt;/s:List&gt; </code></pre> <p>You'll have to figure out how to pass the objects into the property inspector. And the property objects in inspectableProperties will probably need a reference to the actual object they refer to so that the List can display default values. </p> <p>And you can use an itemRenderer function to display different editable approaches based on the type. a TextInput for Strings, a NumericStepper for numbers, and so on.</p>
    singulars
    1. This table or related slice is empty.
    1. POUsing [Inspectable] to build object inspector IN flex
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USJeffryHouser
    1. USJeffryHouser
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POUsing [Inspectable] to build object inspector IN flex
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    1. COI think that describeType would be an overkill here. I think that the most elegant solution would be not to write code for every type. And that's the problem here :(
      singulars
      1. PO
      1. USnooga
    2. CO@nooga Using your suggestion of using the Inspectable metadta; I thought that describeType was the only way to get at custom metadata at runtime. Were you suggesting an alternate? I believe my "interface approach" allows you to use the same "property inspector" for any given type. The code you have to write for each "object" would be "as complicated as you need it to be".
      singulars
      1. PO
      1. USJeffryHouser
    3. COAgree with flextras, there is no reason to use metadata or annotations in this case it offers no benefit I can see. If you were to have to write an annotation for each type to describe the property and potential values what's the difference if you do so in your own object rather than in metadata? Using an interface for a "Inspectable" object should just be a matter of having it return a collection of property/value objects, you can even easily re-use definitions of a particular property/value object as opposed to repetition created by doing it in metadata.
      singulars
      1. PO
      1. USshaunhusain
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload