Re: T5: 5.0.10 new features

[Davor Hrg]

You can instead just accept string
and call TypeCoercer your self in the meanwhile

declare your generic class

AbstractEntityEdit<T,T_ID>{
    private transient Class<T> persistentClass;
    private transient Class<T_ID> idClass;

    @Inject private Session _session;

    @Inject private TypeCoercer _typeCoercer;
....


make a constructor

    public AbstractEntityEdit() {
        Type genericSuperclassType = getClass().getGenericSuperclass();
        if((genericSuperclassType instanceof ParameterizedType)){
            ParameterizedType genericSuperclass = (ParameterizedType)
genericSuperclassType;
            if(genericSuperclass.getActualTypeArguments()[0] instanceof Class){
                this.persistentClass = (Class<T>)
genericSuperclass.getActualTypeArguments()[0];
                this.idClass = (Class<T_ID>)
genericSuperclass.getActualTypeArguments()[1];
            }else{
                //Class is generic and has no Type info
                //it must be provided in init method
            }
        }
    }

declare

    public T getEntity(){
        if(_entity == null){
            if(_entityId == null){
                _entity = createNewEntity();
            }else{
                Serializable id =
(Serializable)_typeCoercer.coerce(_entityId, idClass);
                _entity = (T) _session.get(persistentClass, id);
            }
        }
        return _entity;
    }

you can have the onActivate with the string
and can persist entity id as string also

    @Persist private String _entityId;

public void onActivate(String id){
    _entityId = id;
}


.....

my next proposal for genercis will be for framework
to read generic data and pass in component constructor..

for Example

class SomeGenericComponent<T>

with constructor
SomeGenericComponent(Class genericType)



and declared in a page like this

@Component SomeGenericComponent<Vessel>

framework could then call SomeGenericComponent(Vessel.class)

...
generics are nice for users in a good library or framework
but are also a pain for library developers because people
expect things to work, but type erasure messes things up...

there will definitely have to be a chapter on generics on the doc's
because some nice usage patterns can be acheived, but not without
being aware of the traps.


Davor Hrg


On Feb 17, 2008 9:35 PM, Thiago HP <[EMAIL PROTECTED]> wrote:
> Hi, everybody!
>
> This generics support introduced in Tapestry 5.0.10 is awesome. I was
> already developing an in-house Tapestry 5-related library, including a
> BaseEditPage and BaseListPage that does validation using Hibernate
> Validator, object saving (using our in-house DAO and service
> libraries), dedicated activation context handlers, etc. With Tapestry
> 5.0.10, I could decrease de amount of code needed to code a CRUD. The
> only thing I needed to make it avoid any repetitive code is the
> support of generics in event methods (onActivate, onActionFromXXX,
> etc), something than does not work yet. ;) It would allow me to write
> a generic onActivate(A value) (A is the type of the object activation
> context) in my BaseEditPage and the onActionFromRemove(K objectKey)
> from both my BaseEditPage and BaseListPage.
>
> Howard, what do you prefer: a new JIRA or comments in the original one?
>
> We could try to convince my boss to donate this code to Tapestry. :)
>
> --
> Thiago
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]