locked
Dynamic Data - Default FieldGenerator RRS feed

  • Question

  • User-330204900 posted

    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? [:D]

    Friday, November 7, 2008 6:41 AM

Answers

  • User1641955678 posted

    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

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 7, 2008 9:58 AM
  • User1641955678 posted

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

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 7, 2008 2:21 PM

All replies

  • User1641955678 posted

    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

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 7, 2008 9:58 AM
  • User-330204900 posted

    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 [:D]

    Friday, November 7, 2008 10:08 AM
  • User1641955678 posted

    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

    Friday, November 7, 2008 2:20 PM
  • User1641955678 posted

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

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Friday, November 7, 2008 2:21 PM
  • User-330204900 posted

    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 [:D]

    Saturday, November 8, 2008 7:59 AM
  • User-330204900 posted

    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 [:D]

    Monday, November 10, 2008 5:12 AM
  • User1641955678 posted

    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

    Friday, November 14, 2008 11:29 AM
  • User-330204900 posted

    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 [:D]

    well I hope [;)]

    Friday, November 14, 2008 1:18 PM
  • User1641955678 posted

    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

    Monday, November 17, 2008 2:04 AM
  • User-330204900 posted

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

    Monday, November 17, 2008 3:38 AM
  • User-330204900 posted

    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 [:D]

    Monday, November 17, 2008 4:45 AM