Loading...

All project content is available for reading, but you need to be a member of the project for Subversion checkout of source code, or to create/modify any information.
Login if you are a member. Apply here to request membership (open to all).

Ticket #81 (closed defect: fixed)

Opened 12 years ago

Last modified 12 years ago

Persistence of new web part properties

Reported by: tarjei.lagreid@… Owned by: thomas.leela@…
Priority: major Component: WebPartFramework
Keywords: Cc: tarjei.lagreid@…, lars.flagan@…, vooala@…

Description

If new properties are added to a webpart, they are not persisted at existing webparts.

To reproduce: Create a webpart, add it to a page, create a new property (in code), edit the existing webpart.
The property is not persisted.
However, the property is persisted if the webpart is removed/readded.

This is a bit annoying if a webpart is added to many pages.

Attachments

NumberPart.cs (2.7 KB) - added by steve@… 12 years ago.
Webpart used for testing

Change History

comment:1 Changed 12 years ago by tarjei.lagreid@…

  • Summary changed from Persistance of new web part properties to Persistence of new web part properties

comment:2 Changed 12 years ago by steve@…

  • Status changed from new to accepted

Are you saying that you can see the new property in the "popup" and give it a value, but the value is not saved when clicking save?

comment:3 Changed 12 years ago by tarjei.lagreid@…

Yepp, that's right.

I tried to run the code in debug-mode, and it seems like the properties are fetched correctly from the Epi-properties (in the ApplyChanges() method in PropertyDataEditorPart.cs).

comment:4 Changed 12 years ago by lars.flagan@…

We're also experiencing the exact same behavior. If you have any ideas om how to fix this I'll be more than happy to create a poc for a solution

comment:5 Changed 12 years ago by steve@…

I'm looking into this.

Possibly related #72.

comment:6 Changed 12 years ago by steve@…

  • Cc vooala@… added

I have researched and reproduced the error. I have also found that this only occurs to personalized members inheriting from PropertyData (or decendants) on the web part.

Adding this works as expected (it saves):

[Personalizable()]
[WebBrowsable()]
public int StartNumber
{
    get { return _startNumber; }
    set
    {
        _startNumber = value;
    }
}

The error occurs on both web control and user control based web parts. So, it seems like there is something wrong with the reflection based property data logic.

comment:7 Changed 12 years ago by steve@…

Some debugging have revealed that the new value being put into the property control is being parsed (see more here).

The value is not present when it is supposed to be rendered though.

When I look at the personalization provider in the debugger, I can see that the blob size is the same even with different numbers in the text box, so the value is clearly not being persisted into the blob. The format and contents of the blob field is undocumented from Microsoft.

Seems like the value is lost somewhere between parsing the value and saving it to the database (the web part serialization thingy going on somewhere in there.)

This is a step on the way, though no solution is in sight. More debugging is needed. Feel free to download the source and attach the debugger and start looking, more eyes on the source usually helps. Downloading symbols and asp.net source code also helps.

comment:8 Changed 12 years ago by steve@…

I have devoted the better part of a day on debugging and tracing this error, with nothing to show for it. I have even debugged with the asp.net source, but it is just way to complex to trace.

Basically, I'm stuck. I can see the new values being posted back, and assigned in the property-setter, but it seems like it does not make it to the database, or it is not read correctly on the way back.

Right now, adding new properties to existing web parts is not supported, and as of now - a known limitation. Hopefully some of you have the time and brains to do some more searching. Right now I'm out of time.

I'll leave this open, and hopefully we will find a fix for it later on.

comment:9 Changed 12 years ago by tarjei.lagreid@…

I tried to persist the blob to an xml-file instead (using an XML personlization provider instead of the sqlpersonalizationprovider). The result is the same. This means that the problem arises before the blob reaches the personalization provider.

I also tried to reproduce the same in Sharepoint, but the problem does not arise there (unfortunately? well, that depends :) ). So my feeling is that the problem is somewhere in the editor part (but of course - I'm not 100% sure..)

comment:10 Changed 12 years ago by steve@…

Yes, I also suspect that the problem is in the editor part, and my venture into the asp.net source code indicated that asp.net checks to see if the persisted properties on a web part have actually changed, and not saving if it cannot find any changed values. I believed that the SetPersonalizationDirty call should take care of that.

I suspect that asp.net, during de-serialization, builds a collection of persisted properties, and that collection does not have the new property that has been added. When it checks if a web part has changed, it only compare properties that was present during the first serialization, and then misses the new one.

This theory should imply that changing another (old) value on the property would also lead to the new one being saved, which I cannot see happen. It does not explain why "simple" properties like int are saved as they should.

The attached NumberPart.cs file is an attempt on more debugging.

That Xml personalization provider would have been nice to have :-)

Changed 12 years ago by steve@…

Webpart used for testing

comment:11 Changed 12 years ago by tarjei.lagreid@…

The XML personalization provider I used was this one: http://www.kowitz.net/files/source/XmlFilePersonalizationProvider.cs.txt - by Brendan Kowitz's.
There's also one example (from a larger personalization framework) here http://www.codeplex.com/XmlProviderLibrary.

comment:12 Changed 12 years ago by thomas.leela@…

  • Owner changed from steve@… to thomas.leela@…
  • Status changed from accepted to assigned

After a lot of work I've solved this issue and added some other neat features to the framework. I just need to do a little bit of testing and code cleanup before i commit the files. It wont delay for more than a couple of days.

comment:13 Changed 12 years ago by grenersen@…

Thomas, can you please define "a couple of days"? Last time I checked the definition is 2 :-D

comment:14 Changed 12 years ago by thomas.leela@…

Sorry for the delay. I’m currently awaiting my customer fund the remaining work.

comment:15 Changed 12 years ago by steve@…

Give him some slack - he is working hard in another VIP! (Very Important Project). I have seen the solution, and it looks good.

comment:16 Changed 12 years ago by thomas.leela@…

  • Status changed from assigned to closed
  • Resolution set to fixed
Note: See HelpUser/Tickets for help on using tickets.