The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
|
|
VS C# Databindings
Posted: 27 Mar 08 11:36 AM
|
I have a smartpart that I started in AA - Created a custom extension entity off Ticket. I let AA map the fields initially. I then started editing the smartpart in VS. It is a support file and all is going well with that. The smartpart inserts a ticket and data into the extension table.
I added more fields to the custom table and refreshed the entity in AA then rebuild the Interfaces. I then added some fields to the smartpart in VS. I updated the data bindings in the OnAddEntityBindings() event.
The textbox I am testing is this:
asp:TextBox ID="ManuName" runat="server">
The code I added to OnAddEntityBindings() is this:
BindingSource.Bindings.Add(new Sage.Platform.WebPortal.Binding.WebEntityBinding("ODMCERTPC.Manuf_Name", ManuName, "Text"));
The data in this new textbox is not saving to the db although the ticket and extension table are getting inserted. Am I missing a step? I also tried a ctrl-Build Web Platform and restarting AA and rebuild/redeploy.. |
|
|
|
Re: VS C# Databindings
Posted: 27 Mar 08 11:45 AM
|
| Got it - It was the underscore in my field name. In SQL server it is Manu_Name. When AA creates the entity it drops the underscore and calls it ManuName - BAD AA!! lol. A heads up to others I hope. Match your bindings to the AA entity - which apparently takes some liberties with the alias name - not the actual database name. |
|
|
|
Re: VS C# Databindings
Posted: 28 Mar 08 6:46 AM
|
| Ya, when generating the Entity AA will remove some characters to make them more object friendly. Glad you figured it out. |
|
|
|
Re: VS C# Databindings
Posted: 28 Mar 08 12:59 PM
|
I dont see the value in this at all. The entity should follow the database structure in my opinion. This increases the likelihood for defects just like the one Steve encountered. I use underscores with multi-word cases in all of my database and object design because I feel it makes it easier to read: Account_Manager vs AccountManager for example. I will take the underscore every time.
Just my opinion of course...
Timmus |
|
|
|
Re: VS C# Databindings
Posted: 28 Mar 08 1:03 PM
|
Sure, it is a matter of personal taste. However in API design when things are exposed publically Pascal Casing is the preferred method in most Tomes.
Mark |
|
|
|
Re: VS C# Databindings
Posted: 28 Mar 08 1:19 PM
|
Not overriding what a designer/developer has explicitly developed is the preffered behavior. Anyone that assumes their preferred method is the correct method is arrogant. Leave my stuff alone. I dont understand why vendors insist on mucking with these trivial details. It adds no value and only causes inconsistencies that lead to defects.
I would be cautious when arguing what the "standard" is, Mark. There are a gazillion standards that all contradict eachother. Sage is not the final authority on the "right way".
Timmus |
|
|
|
Re: VS C# Databindings
Posted: 28 Mar 08 1:37 PM
|
I hope I did not come off as arguing the decision that Sage made on cleansing on the names. Since I do not speak for Sage. I cannot say weither there was a reason when it came to the usage of NHibernate or what ever the decision was made. Frankly naming is really a matter of choice. As you could imagine, like you I like to get into discussions on what is the best way for the community as a whole. Sun, Sage, MS, Oracle all have their way, as do the Gazillion others. As such it could have been that the dev team was looking for a API that more resembled the 'Outlined' best practices in the "Framework Design Guidelines" by Brad Abrahams and Krystof Cwalina http://www.amazon.com/Framework-Design-Guidelines-Conventions-Development/dp/0321246756/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1206728903&sr=8-1 . It really looks like they are following MS's conventions. I think the only standard I would argue is when creating a .net customer facing API/Framework the conventions that MS took in designing the BCL should be conformed to to ensure little to no retraining to use the new libraries. If you have not read, I would suggest doing so the design guideline book I refered to earlier.
But I could be wrong.
Kind Regards,
Mark
|
|
|
|
Re: VS C# Databindings
Posted: 28 Mar 08 3:10 PM
|
I dont think you made the decision, Mark  and I definitely dont blame you. I apologize if my frustration got the best of me and my tone was less than constructive. Point is that I am fed up with vendors making assumptions that cost us time and money when they could just as easilly NOT make the assumptions to begin with. No one asked Sage to modify the entity properties to vary from the database structure nor did Sage ask us if we wanted them to. Yet again someone made a design decision in a bubble without any real world feedback...
Timmus |
|
|
|
Re: VS C# Databindings
Posted: 29 Mar 08 12:28 PM
|
FYI - Entity Names and Properties are derived from the "Display" name.. not the real Table/Field name(s)... and the "casing" is also modified as Mark pointed out.. very nasty.. and this is not published anywhere!
--
RJLedger - rjlSystems |
|
|
|