| org.apache.myfaces.orchestra.dynaForm.annot.ui.DataProvider |
Line |
|---|
| this class is very jsf-specific, but is not under a jsf package. |
32
|
| org.apache.myfaces.orchestra.dynaForm.annot.ui.Length |
Line |
|---|
| does this control the amount of space the input component takes up on the screen, or the number of characters that the user can type into it (including scrolling support), or both? |
33
|
| org.apache.myfaces.orchestra.dynaForm.annot.ui.Temporal |
Line |
|---|
| is the above paragraph true? <p> This works much like javax.persistence.Temporal but permits the use of any date library. |
36
|
| org.apache.myfaces.orchestra.dynaForm.annot.ui.UIComponent |
Line |
|---|
| is this really flexible enough? The enum here is hard-wiring the possibilities, but a user's custom component might also have alternate renderers. Maybe just a component-type string should be specified here, with the Dynaform doing a normal factory-lookup to get the appropriate component type? <p> Note also that this is very JSF-specific. |
35
|
| org.apache.myfaces.orchestra.dynaForm.jsf.component.DynaForm |
Line |
|---|
| why is this property marked with a JPA Transient annotation? |
96
|
| before writing out the component, look for an existing component with that fieldname inside the parent. If it exists, then just skip the component creation. This allows the user to do custom layout for some of the fields. This might also make the @UIComponent annotation obsolete. |
110
|
| fieldName is an unused parameter |
125
|
| why can't value.getClass() be used for the classname part of the uri? Maybe because the value EL expression can map to a null property when creating a new instance? <p> |
222
|
| Can we get rid of this attribute? Either call <code>getValueBinding().getExpressionString()</code> or create a special ValueBinding subclass that takes a "base object" parameter which we can point at the result of evaluating the main value expression. |
262
|
| document this properly. What does this do exactly?? |
371
|
| clean this method up. It still had artefacts from when this code was in a separate Renderer class. |
638
|
| need to figure out whats the best way to recreate the components |
747
|
| org.apache.myfaces.orchestra.dynaForm.jsf.guiBuilder.impl.myfaces.MyFacesGuiBuilder |
Line |
|---|
| SANDBOX COMPONENT - promote to tomahawk */ |
47
|
| SANDBOX COMPONENT - promote to tomahawk */ |
116
|
| org.apache.myfaces.orchestra.dynaForm.metadata.MetaField |
Line |
|---|
| what about compound keys? |
50
|
| remove this method, it is jsf-specific |
128
|
| org.apache.myfaces.orchestra.dynaForm.metadata.impl.ejb.AsmHelper |
Line |
|---|
| this looping through all methods and calling getMethodDescriptor on each one is not very efficient. It might be nice to build all the descriptor->Method mappings once and cache them in a map. The question then is how long to hold onto that cached data though. And where to store it, as keeping the cache in a parent classloader will prevent unloading of any of the classes that those Method objects are on, unless weak references are used. For now, keep things simple.. |
210
|
| org.apache.myfaces.orchestra.dynaForm.metadata.impl.ejb.EjbExtractor |
Line |
|---|
| fix this import; this non-jsf class should not import jsf-specific stuff |
63
|
| this only works when annotations are used, but annotations are optional in JPA; external xml config can also be used. |
280
|
| org.apache.myfaces.orchestra.dynaForm.package-info |
Line |
|---|
| add nice way for Orchestra introspection to controllably cascade down into referenced objects. In particular, where a record has a foreign key to a static "lookup" table (eg "units" or "department") it would be nice to be able to render data from fields on the referenced object inline in the parent. Editing is a little trickier; it is the foreign-key that needs to be updated, not the displayed field. Maybe each such linked-field could be rendered as link that pops up a window to select a different record? These records would always be N:1 relations of course. <p> Displaying linked data that is not a "lookup table" should also be possible, and editing fields on those records should be fairly easy. Not sure that allowing editing of fields where the relation is anything other than 1:1 is a good idea though. <p> |
11
|
| add an "extensible object" framework where a proxy is auto-generated to allow properties to be added to a model object. There are two forms of enhancement: joined records and transformed data. When in display-only mode both of these are pretty straight-forward. Of course DynaForm will then need to know how to merge the persistence data for two objects. Editing a field that exists on a linked object should be reasonably straight-forward. |
25
|
