Frans, in another thread you said

A fine grained validation framework will be added in v2.0

Just curious if you have any more information what that will be about?

Thanks

Much easier way to add validation logic and more validation points to the framework.

Well, that sounds good. Also anything to help a developer "bubble up" errors from DAL to UI without introducing dependencies is good. I'm thinking of building a broken rules collection in my BLL, although I'm not using CLSA (but that's where a buddy of mine got the idea).

You've expressed reticence to implement IErrorInfo in entities, although I looked closer at that and it's not tied to UI; it's part of System.ComponentModel, which you already include in entity files. I wonder if that's something that's worth considering.

IDataErrorInfo is slated to be implemented on entities indeed. I'm currently busy writing EntityView(2) classes for 'dataview-esk' behavior on entity collections (sorting/filtering in memory) which touch databinding as well, which is the feature I'll be addressing after this, and thus IDataErrorInfo

One thing I'll get rid of is the IValidator interface based validation classes which are generated. All validation will be done through base classes, as interface based validation isn't extensible. That will be the biggest migration point for customers, the rest will be rather smooth actually .

Design time databinding will be a challenge, but it already works pretty well, so I think it will work out great. The main challenge will be asp.net 2.0's incredibly stupid databinding, but without challenges, software writing would be boring .

That's awesome, Frans, and thanks for not only doing such a great job on the product but also of keeping us all so informed and listening to our suggestions (good and bad).

Is there a target for type safe collection in 2.0. something like generics

DataAccessAdapter adapter = new DataAccessAdapter( ); EntityCollection< CEntity > c = new EntityCollection< CEntity >( new CEntityFactory( ) ); adapter.FetchEntityCollection( c, null );

What about Stored Procedures!!! Is the design now to call the sp, then interrate though the DataTable and build Entity objects then store them into the Entity Collection. It would be nice to pass a delegate to the factory or the Adapter and populate the EntityCollection object within the framework. Just to have the factory/adapter or what you think would be a good place to call this.

something like this. (sorry for the generic syntax that does not exsist, just want it!)

// delegate definition public delegate void StoredProcedure( );

public StoredProcedure sp;

DataAccessAdapter adapter = new DataAccessAdapter( ); sp += new StoredProcedure (RetrievalProcedures.spRylandComCommunityExtract); EntityCollection< CEntity > c = new EntityCollection< CEntity >(new CEntityFactory( sp ) );

Or

adapter.FetchEntityCollection( c, null, sp );

I don't know what you have in mind for this. Could you throw so idea out too. I don't know if you had some reason that you did not want to do this, could you share it with us. Thanks.

sburtonctr wrote:

Is there a target for type safe collection in 2.0. something like generics

DataAccessAdapter adapter = new DataAccessAdapter( ); EntityCollection< CEntity > c = new EntityCollection< CEntity >( new CEntityFactory( ) ); adapter.FetchEntityCollection( c, null );

yes, this is planned.

What about Stored Procedures!!! Is the design now to call the sp, then interrate though the DataTable and build Entity objects then store them into the Entity Collection. It would be nice to pass a delegate to the factory or the Adapter and populate the EntityCollection object within the framework. Just to have the factory/adapter or what you think would be a good place to call this.

something like this. (sorry for the generic syntax that does not exsist, just want it!)

// delegate definition public delegate void StoredProcedure( );

---

public StoredProcedure sp;

DataAccessAdapter adapter = new DataAccessAdapter( ); sp += new StoredProcedure (RetrievalProcedures.spRylandComCommunityExtract); EntityCollection< CEntity > c = new EntityCollection< CEntity >(new CEntityFactory( sp ) );

Or

adapter.FetchEntityCollection( c, null, sp );

I don't know what you have in mind for this. Could you throw so idea out too. I don't know if you had some reason that you did not want to do this, could you share it with us. Thanks.

The design for stored proc support isn't finalized yet, I can't elaborate on that now. What's planned is stored proc support for persistence of entities, how that's realized isn't finalized yet as first some other features have to be implemented.

Ah, thats great news. I do like the CSLA broken rules collection, and IDataErrorInfo seems to be obeyed by most of the UI components I have used. I have my own template implementation but it would be nice to see it make it into the core product.

As a matter of fact, I've implemented the code to support IDataErrorInfo 10 minutes ago (in the v2 codebase ). Still it's a silly interface though, as it assumes error message production is contained INSIDE the object it's implemented on, but too many people have requested it, so it's added.

Still it's a silly interface though, as it assumes error message production is contained INSIDE the object it's implemented on.

Yeah, the version I banged up used attributed coclasses for holding the rules and wired them up to the derived entity (CSLA broken rules style) using reflection. Not good in a scenario with massive resultsets though.