Customize the table fields on runtime


Author
Message
Jimmy Lam
Jimmy Lam
StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)
Group: Forum Members
Posts: 4, Visits: 9
Hi Strataframe experts,

Does StrataFrame allow of customize the database table's field during runtime? For example changing the datatype, Something which is similar to the Database Development Toolkit. The purpose of these, is to allow our customer to customize the fields themeselve without re-coding and re-compilation of the codes. Therefore we developers could save up plenty of time for the customization.

Kindly advise and welcome for any kind of comments
Thank You.

Replies
Jimmy Lam
Jimmy Lam
StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)StrataFrame Beginner (4 reputation)
Group: Forum Members
Posts: 4, Visits: 9

Hey guys,

 

Once again, thanks for the comments. My needs is easy, I want it to be easy for me and my customer to do the customizations, and I don't wants to keep different set of BO Rules with me.

 

The scenarios is simple, for example Customer A would like to have field Country and Branch to be mandatory, while Customer B would like to have field Branch and Division to be mandatory instead. Furthermore some customer would like to have their own comments on each field and they want it through out 1000+ of fields. This process of customization would be hazardous for me to complete, because I have 100+ of customers, and is nearly impossible for me to maintain different set of BOs.

Thanks Smile

Trent Taylor
Trent Taylor
StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)StrataFrame Developer (14K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 7K
Though I still don't understand how you would implement this in a sense of producing a UI, you could still come up with a solution for this on the BO/DAL side of things.  It sounds like you want to have an application that your end-users highly customize the forms, data, etc.  In a sense, it sounds as though your end-users need a bit of development experience as well.

We have created an environment for some of our reporting to allow our end-users to create queries and data sources that are not distributed with the software by default.  This allows them to create custom reports and queries without ever having to tallk with us...so we both win.  However, if all of this had to translate into user input and dialogs, well, it would become far more complicated.  Past just creating a grid and teling them to "get after it," you are going to have a difficult time with the UI having to be so flexible as well...at least from my perspective.

So the answer is, yes, with some work you can definitely create this type of environment.  But clearly this is not going to be the norm for most development environments past reporting.  I hope that at least gives you an idea of what you are looking for here.

Greg McGuffey
Greg McGuffey
Strategic Support Team Member (4.8K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
Jimmy as I think about this, I really don't see adding dynamic columns as being of any help at all. I did a bit of a mental exercise and the following became glaringly obvious:



- unless the users are developers/dba, managing dynamic adds to a database is going to be hard. You have to consider indexing, valid names, defaults, constraints and any server specific issues, such as row size limit on SQL Server 2000 (8060 bytes) or the related row size performance issues with SQL server 2005. I just see all sort of issues and no solutions for trouble the users could get themselves into. (Image the users adding varchar(8000) comments fields to the 10 fields in a table...booom!)



- Allowing user to change the database will make updating the database on your end even harder. I.e. if you need to add a column to a table for some base functionality, but the user already maxed out the table width, your screwed. You won't be able to use the DDT as it would remove any user customizations. I'm sure there are ways around all of this...but wow, that's a lot of work.



- Assuming you manage the dynamic changes (and I mean really dynamic, were you don't know what they might do), then you would need to make your BOs dynamic enough to get to this data. You'd probably have to use regular .NET binding, as new custom properties wouldn't have a bindable property associated with it.



- As Trent mentioned, managing a UI for this will be...er...fun. You'll have to track all those custom columns, the display names, control types, if they are a list, the list source and some how get that on the screen so the user can see it and use it...wow.



The two examples you mentioned are fairly contained though and Ivan's suggestions seem like they'd work better anyway.

1. Dynamic business rules. It seems to me to be more feasible to build a dynamic rule engine than change the db. The BOs are all wired to process any business logic already, you'd just use a dynamic engine for that process. Imagine allowing the users to specify, for example, what fields are required. You could easily just update the RequiredFields property of the BO at run time, based on a set of fields the user has configured and you stored in a db table (which will have its own BO, with a method to get the fields for that table...that you call from the check business rules event each bo, or better in a base business layer that just passed in the table name).



2. Adding comment fields. I see two ways to do this. The easier way is what Ivan suggested, of simply allowing a set number of fields to have optional comments. They simply turn them on off, perhaps set a name. Store this in a configuration table, your good. You could also have a common "comments" table, that tracked the comment, the table the comment is associated with and the PK for the row. This allows for more flexibility, but makes development more complex and can have some performance issues too.



In any case, I'm just throwing out some thoughts and hope they stimulate your development process a bit! BigGrin
GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...





Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search