Hi!

I have been thinking about developing a "POJOView" that is, something exactly like ADO.NET "DataView", but for POJOs instead of DataRow, IMHO all I have to do is implement:
IBindingList, IList, ICollection, IEnumerable, and ITypedList for collection handling and ISupportInitialize to handle some DataGrid glitches

I will be using what I learned from http://noiseehc.freeweb.hu/databind.html
and from HOW TO: Implement a Custom DataView Class in Visual Basic .NET http://support.microsoft.com/kb/325682/EN-US/, of course I will code it in C# not in VB.NET

I am doing this because AFAIK NHibernate doesn't have a component (maybe I am wrong?) like this and I would be happy to contribute it to the project if you guys are interested and me how to send the code to you

Hi

Sounds interesting..

Have you seen this?

http://sourceforge.net/projects/objectviews/

Yes, something like that, but specialized for NHibernate, why specialized? well because things like sorting or filtering have to be specialized for the particular Object query language... it is sad that there is no standard for object querying

Yes. There needs to be a project that fills this need. I made ObjectViews but haven't been working on it lately. There are a lot of gaps. I've been talking with some other people recently about combining efforts/ideas so this post was rather timely.

We'll continue our conversation here for all to participate in.

I am very interested in ObjectViews. Luggage has a great start on it. I think we should continue on with this project and finish it out.

We can merge in any code that you've got... for sorting and filtering or other functionality.

The one issue open source has left in my mind is that there are usually 3-5 projects that do the same thing and are all about half implemented. :?

That's so true.

Therefore, last week I started with creating the 'final ObjectView' ;).
Essentially, this comes to combining all good aspects of the existing solutions (the JoinView sample, ObjectViews, NView and my own custom solution) and make that to a package should fullfill most needs.

These are the requirements:

1. The solution should only have references to standard .NET libraries (so no relation to any O/R mapping framework).
2. Fully implement IList, IBindingList, ITypedList and IListSource
3. Binding complex properties (like Customer.Address.Street1)
4. Nested ObjectViews for related collections.
5. Designer support.

I'm currently halfway implementing. When points 1 to 4 are ready, the first version will be published somewhere (Donald (luggage), is it wise to use the ObjectViews SourceForge project for that?).

After releasing the first version, everybody can review it and give their 2 cents. This will obviously result in various extra requirements that will result in sub-projects. Anyone with a little spare time can take up one of those projects and implement it. Subprojects that I'm currently thinking of are:

- Extended support for NHibernate (binding sets and maps) and other O/R mappers.
- Designer support.
- Conversion to read-only DataSets for reporting.
- Batch-retrieval of rows in combination of the paging possibilities of O/R mappers (or a handwritten DAL for that matter).

Comments?

Martijn

Yea, we can use the sourceforge project. We just need to keep the old ObjectViews on there for a while. I use it in a few projects at work. I don't think it'll take very long to merge/replace all the functionality in it though.

I agree with your requirements completely. There was mention of a "Specialized" version for Nhibernate. I think this can be accomplished with a second optional assembly (if needed at all).

I'd like to keep the project focused (do one thing, do it well), but there are a few related databinding tools that may be required for using it smoothly.

What is your sourceforge account, Martijn? I'll give you the access you need to the project.

Hi!
I think that it might be a good idea to make this ObjectView specialized for Hibernate, to make it attrative for:
1) .NET 2.0 Users (an Object View is included in .NET 2.0 with basic functionality) That is, if we provide only basic functionality, it might become obsolete when .NET 2.0 is release
2) Make NHibernate attractive for hightly visual programmers.

A generic (O/R agnostic) ObjectView can provide basic collection operations (Add, Delete) but it cannot provide complex operations like sorting or filtering because then it would depend on the particular object querying language and every O/R in the market uses a differeng language for that.

Maybe what should be buillt is something more like ECO expression handles take a look at:

http://www.borland.com/us/products/delp ... rial1.html

and at:

http://www.borland.com/us/products/delp ... rial2.html

Of course, the UML diagramming is outside the scope of this discussion, what we need to focus in is the way the Expression handles can be used to specify "visually" which objects are going to be loaded (in ECO, using an OCL Expression, in NHibernate, it should be possible to do the same using an HQL expression)
It is also nice how master-detail relationships can be handled visually.

Another interesting "visual" functionality, is the ability to configure the connection between a particular ObjectView (ExpressionHandle) and the current ECOSpace (througn the rhRoot). This means that after someone builds a bussinesobjects layer that works, a developer can easily (and fast) build an UI that works.

Copy&Pasted from Borland Site: "The ReferenceHandle component, which was placed on the form by the ECO Application wizard, provides the link between the EcoSpace and the Winform. A ReferencetHandle can be set to reference a specific object in an ECO Space or the entire ECO Space. This is how the ReferenceHandle is being used in this example. It is important to set the reference handle to use the ECO Space we have just defined in our model, set the following parameter for the rhRoot component.

EcoSpaceType = ContactManagerEcoSpace.TContactManagerEcoSpace

The ExpressionHandle is linked to another handle, either an ExpressionHandle or a Referencehandle, and evaluates an OCL expression to provide a resulting object, collection or value. It is possible to daisy chain ExpressionHandles where each handle evaluates its result from the results of the previous handle"

IMHO this means we could build a component to "visually" bind a particular NHibernate session to a our WindowsForms UI...

I think all this could make much easier for non O/R RAD programmers to adopt NHibernate... What do you think?

That's great. Should we keep the name 'ObjectViews'? I can imagine that this causes some confusion when there are 2 non-compatible version around.


I was thinking along the same lines. A second assembly with a subclassed ObjectView.



martijn_b at users.sourceforge.net.

I personally like the technological approach of hibernate but it is hard to spread my enthusiasm to my users if they don't have all the grid features they are used to.
So I think this will be a huge benefit to get hibernate accepted at the user level which is really important to me.

In fact, I was hoping that .NET 2.0 would make an ObjectView obsolete, but unfortunately this isn't true. For example, with the .NET 2.0 BindingSource, it is still impossible to bind properties of related objects (like Customer.Address.Street1).



I think that an ObjectView should provide sorting and finding based on the objects that are already in the underlying list. Filtering isn't even supported with the (.NET 1.1) IBindingList interface, so that's a different story.
The best solution would be to raise events when sorting that enables you to hook your own sorting code to the ObjectView.



Although, very interesting, I think that some of the ECO capabilities are way beyond the scope of a generic ObjectView. Maybe it's something for a specialized ObjectView but I wouldn't call it an ObjectView anymore but a Winforms-NHibernate connector.

I like the name ObjectView because it sounds like DataView, but for Objects. I don't think an incomatible version as part of the same project should be an issue because:

A) It's pre-alpha, API's are expected to change.
B) We can keep the old version around, people can upgrade when they want to use a new feature
C) They are both implementing IBindingList so they really shouldn't be THAT different.

Yes, When I made the original I was hoping it would be obsoleted by .NET 2.0. I wanted to focus my efforts on my application, not on an ObjectView (even though it was kinda interesting). I think we have a similar goal in mind, Martijn.

luxspes, you mentioned an "Object View" in 2.0? Where is it, exactly? I'd like to look at it but can't find it (I'm on Beta 2).

For ASP.NET :
Documentation in http://msdn2.microsoft.com/library/9a4kyhcx.aspx (Or System.Web.UI.WebControls.ObjectDataSource in http://msdn2.microsoft.com/library/dx70zk47(en-us,vs.80).aspx)

For WindowsForms:
Documentation in http://msdn2.microsoft.com/library/cw8f1c66(en-us,vs.80).aspx
Sample Application in http://msdn2.microsoft.com/library/baya8sx4(en-us,vs.80).aspx
(System.Windows.Forms.BindingSource) http://msdn2.microsoft.com/library/ms158145(en-us,vs.80).aspx

So, the names are

"BindingSource" for WindowsForms and "ObjectDataSource" for ASP.NET, IMHO, this components might make our ObjectViews obsolete... unless we concentrate on providing funcionality that it is not available in them

IMO we should classificate our "extra funciontionality" in :
1) Extra functionality that can be O/R agnostic
1) Extra functionality that depents on the O/R (like ECO's ExpressionHandle)

Posting on this site is becoming quite painful (this is the second attempt at this message). I vote those interested int he project begin discussion on the sourceforge page (it's SLIGHTLY less annoying) unless there is a better place.

http://sourceforge.net/projects/objectviews/