Hi DD Team, I was wondering where does the Default FieldGenrator live, i.e. the one that runs if none is supplied?

e.g.
DetailsView1.RowGenerator = new AdavancedFieldGenerator(_table);
or
GridView1.ColumnGenerator = new AdavancedFieldGenerator(_table);

And is there any way of extending it? for instance if it is the DynamicDataManager on the page can this class be inherited and a new Default FieldGenerator implemented?

Hope this makes some sense?

Hi Steve,

It's inside the DDManager, but it's private and can't currently be extended.  However, we're looking to change this.  One idea is to let you pass a generator (or rather a lambda that creates one for a MetaTable) at the time you create your model, and it'll be used as the new default.  This way, no need to change all the pages.

Thoughts on this?

thanks,
David

davidebb:

One idea is to let you pass a generator (or rather a lambda that creates one for a MetaTable) at the time you create your model, and it'll be used as the new default. 

That's exactly where I was going with this as it would make adding column level security to an existing site real easy.

The other thing i was thinking of was chaining the colum generators i.e. the input for one is the output for the next so instead of passing in the table you waout pass in the result of the last query and the query would always be a IEnumerable of columns, it's just a thought

One issue is tha IAutoFieldGenerator deals with DynamicFields, not MetaColumn.  Maybe the right thing to do is to not use that interface at the model level, and instead stick to using IEnumerable<MetaColumn>.  This way it becomes applicable to scenarios that don't use GridView/ListView.

David

Sorry, I meant GridView/DetailsView, which are the two controls that use DynamicFields.

That sounds more the thing David, I hope that something of this sort comes along as it will make adding global changes without messing about with each PageTemplate and CustomPage

Having thought about it David I think that the Lambda should return a List of DynamicFields as in the IAutoFieldGenerator as all you will be able to do by returning an IEnumberable is drop and sort fields and one of the things I you would want to do is control the DynamicField i.e. change its mode make it ReadOnly etc.

I don't think this would be a major drawback, as you may want to sort or drop fields based on some rules so chaining the lambdas wont be as important as having a centralized FieldGenrator.

Hope I'm still making sense

That's a good point Steve.  The drawback of using DynamicFields is that it's specific to GridView/DetailsView, and we'd like the generator to apply to other situations as well (e.g. 3rd party controls, ListView, non-WebForms scenarios).  We could still use DynamicFields simply as a way to help the relevant data, but they could not be used directly outside of GridView/DetailsView.  The alternative is to create a new class that holds the data (MetaColumn, mode).

But either way, I agree that just the MetaColumn is insufficient for the full range of scenarios.

David

What I'm thinking is based on the metadata being read-only if it were read-write then perhaps you could set or add attributes on the MetaColumn sutch as readonly and then if the default field generator could set the mode to  

DataBoundControlMode.ReadOnly

then you could have your security per column

well I hope

Note that there is only a single instance of each MetaColumn/MetaTable running in the app domain, so if you were to dynamically change their readonly flag for each request, you'd get random conflicts between threads stepping on each other.  Unless I totally misunderstood your comment, which is quite possible! :)

David

Ah! so you'd still need a FieldGenerator to do the read only on fields

Well after this chat David I'm beginning to think that the IAutoFieldGenerator is the most powerfull tool to use as a Default FieldGenerator althought the flexibility of returning an IEnumerable still has it's merits.

I guess we'll just have to wait an see what you and the team come up with