Customizing files without affecting baseline application

Startbeitrag von Parrot am 27.07.2009 14:27

We are rebuilding our application suite with WinDev . We have several hundred customers with a number of them requiring customizations specific to their site. In order to support this environment, we may need to add custom fields for a customer into an existing baseline file. We would like to add this field to an existing baseline file only at the customized customer’s site without affecting the baseline analysis that supports the non-customized customer(s). We also need the custom field to be retained in the customer’s file after new releases of the baseline may also add fields to the file. Does anyone have experience in supporting this?

Regards,
Spencer

Antworten:

we had a similar problem and we keep the base tables without amendments.
as a solution to customers that need to create more fields we create new tables (we call them extension tables) with the same unique key of the base table (1 to 1 relation) with the new fields.
it's probably not the best but it was the only solution we found to keep the base tables unchanged.
we create this sort of tables only by programming keeping them out of the analysis.

the only thing you have to be careful is when you change the unique key of the base table, you have to rebulid the extesion table accordingly.


von Paulo Oliveira - am 27.07.2009 14:51
Thanks Paulo,
Your solution makes sense to me. I've done that with other applications in the past as well. I was hoping that WinDev might have some type of inheritance where the base application analysis could be inherited and additional items added in a custom analysis, but I can't find where this is possible in WinDev. I'm happy to see that someone else has been through this problem previously and you've had a successful outcome.

Best regards,
Spencer

von Parrot - am 27.07.2009 16:53
I don't know if windev manage this kind of problems, i can't find out how.

If you find a better solution please let us know.

von Paulo Oliveira - am 27.07.2009 17:07
Hi All,

Don't know if this is what you want, but cant you dynamically define a file in code using
hdescribefile? That way you can keep a base analysis and create whatever you want extra dynamically.

HTH

Bosher

von bosher - am 27.07.2009 18:08
Haven't tried, but maybe the 'configurations' possibility can help.
Menu Project->Project Configurations->...

Another option might be 'branching' using the SCM options.
Menu SCM ->Branches->...

Just my 2 cents,

Peter H.

von Peter H. - am 27.07.2009 19:42
Hello Spencer

We do this on a small scale with a coupls of link files. One has information in each record so it can be used to set up the data on a specific window and the other has one of each type of possible field type and fields for the calling process to be able to extract the type of data the record contains. From the old days Windev still provides a 2 digit file alias and we have always used that as part of our primary key field name and this also is part of of the call process to the link table to provide a unique key because with various processes calling the link table and providing their own numeric primary key values, a second unique source identifier is required to keep the records unique in the link table. The 2 digit file alias is really very usefull in writing generic code.

e.g. The Creditor file has a file alias of "CR" with "CRPKey" as the primary key field name so I can call related linked records with SrcFile + SrcPKey + RecType as part of a global proc. A call to the link file with "CR"+12345+"CUR" will find the correct record and return the value in the currency field of the link file. The Window name is used to call the file holding the field details so the process can also return a user description of the field if it is required to have data and field descriptions for specific windows. We only use this in a fairly simple way at the moment but you could set up the window link file structure to have provisions for field positions, colours, validations etc.




Regards
Al


von Al - am 27.07.2009 21:11
Thanks to everyone for your suggestions. I'm going to prototype a solution based on all this great input and see how the testing goes.

Thanks very much for all your help.

Spencer

von Parrot - am 28.07.2009 12:14
Hi,

Another very simple solution could be adding an extra string type item into the base files that need customizing. In this item you can store several extra items, separated by tabs.
You can use extractstring to retrieve these values. The size of the item depends on the maximum length of the custom data.

Regards,
Piet

von Piet van Zanten - am 28.07.2009 12:28

Re: Customizing files without affecting baseline application

Hi...

there is one inconvenient to this solution, it's that when the user want
not only a customized, but also a modifiable schema, you end up writing
code to modify the files, again and again...

Personally, I prefer to go another route:
I have ONE memo field in each file in which I store ALL the custom
fields values the following way:
F1=xxxx
F2=yyy
F3=kjjkjkkjjkjjklklkkjkj
Message forwarded from pcsoft.us.windev

von Fabrice Harari.pcs.crosspost - am 28.07.2009 12:45
Hi,

Just another thought. It's possible to use a component which will have it's own analysis, screens and reports. You'll be able to add the additional tables and give tailored personalized screens and reports to this customer.

You simply have to create personalized builds for these customers... or simply check when the application start if a personalized component is available and then load it. Working with the Component* functions will tell you if a specific component is used.

But maybe in the end this will be more complex. It depends what level of personalization you need. For internal components, I don't know if you can load them "live" or not. I did not had the time to test them in WD14 - since they can now have their own analysis, etc. But can we simply remove them from a build? And compile them in an independent loadable library? This I don't know.

Some search and usability / maintainability tests are required.

As other have already suggested (it serves as a summary at the same time):
- For basic data personalization, the "memo" field is the simplest approach. The downside is that it's not easily indexable and workable for display / sorting / filtering logic.
- Another way to do it is to have "free" columns in some tables that are indexable and that customers can use to put what they want - you ask them to define the label of the field.
- More advanced data personalization is to describe a new table with proper fields and indexes. This is not that much complex and you can query the table and play easily with the data. Since you decide the "link" logic, it is easily maintainable. (Using component - external or internal - can help but is not required.)

Hope this helps.

Best regards.

von Alexandre Leclerc - am 28.07.2009 15:04

Re: Customizing files without affecting baseline application

Parrot a écrit :
> Thanks to everyone for your suggestions. I'm going to prototype a solution based on all this great input and see how the testing goes.
> Thanks very much for all your help.
> Spencer
>
>
Hi

As Bosher said, user hdescribefile.
We use this kind of trick since 2-3 years on our application without big
troubles.
I advise you to create a file with your fields descriptions.
At start of the application you describe the file with the same unique
key, then add the fields as needed.
This way you can have a numeric field for numeric values, string fields
of the needed length.
This will avoid to access to a blob and parse it in a ugly functions.
Just :
IF HReadSeekFirst("File","Key",sSearchedValue) THEN
FormField1 = {"File.Field1",indItem}
FormField2 = {"File.Field2",indItem}
END

If the file is describe as extern in the project with "EXTERN File"
A better way is to describe it as a data source 'File is Source"
Then you can even use
sSearchedValue is a String
IF HReadSeekFirst("File","Key",sSearchedValue) THEN
FormField = File.Field1
FormField = File.Field2
END

We also use dynamic compilation to enhance/personalize some feature of
our software.

Bye
Goof
Message forwarded from pcsoft.us.windev

von Goof.pcs.crosspost - am 28.07.2009 15:49
Hi everyone,
After reading through all the ideas, here's what I've ended up with.
1) I have created a custom project that will contain all my custom windows, reports, etc. I have associated the main application's analysis with the custom project since most custom objects will use the main application files rather than custom files.
2) I then created a custom analysis that contains all my custom files. This custom analysis is NOT associated with the custom project.
3) When I create a custom window, report, etc. requiring access to custom files then I do the following in the global declarations:
CustomFile is Data Source // define the custom file as a data source
HDeclare("CustomFile", "C:\directory where WDD is located\Custom.wdd", "")
4) An example of a read of the custom file would be:
HReadSeekFirst(CustomFile,"KeyField",sSoughtValue)

I like this setup because it provides access to analysis that shows all the various custom files with their items - changes to the files can be tracked through the analysis easily. I can also include WinDev's WDModFic in my setup installation so that custom files are automatically updated with file changes.

I'm not sure if my thinking will work for everyone, but wanted to pass along what I have figured out at this point.

Thanks agains for all your help,
Spencer




von Parrot - am 31.07.2009 13:02
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.