I have been using a "Multiple lines of text" field (a note field) to store some HTML. Testing revealed that the HTML in the field was not quite the same as intended.
Further investigation showed that when a list item with note fields is saved, any blocks of text that resemble script are removed from the rich text in the note fields. This occurs either when saving the item through a form in the browser, or when using the "update()" API method.
The process that removes script sometimes gets too eager to "cleanse" the HTML - I found that it was removing the following inline style (not my HTML design, I hasten to add!):
BACKGROUND-IMAGE: url(http://some.site/info/communications/PublishingImages/box_1024.gif);
I didn't experiment further with this style to see whether adjusting the exact text (for example, adding quotes) might mean it was retained.
Sunday, February 15, 2009
Thursday, February 12, 2009
Unlearning My Development Process
Two years - that's about the length of time I have been developing on the SharePoint 2007 platform. Over that time I have been using roughly the same development process and tools, with a few additions to my "tool-belt", and a few tweaks to the steps in the process. But no radical shifts.
Must admit I have always developed from the point of view of creating a deployable solution first, and adding functionality to that solution as I go along. Means that when the functionality is working and tested then I have a package ready to ship. Rather that than developing the packaging as a final task, and then needing to retest the deployment outcomes.
And I like CONTROL over the solution, so I have been hand-crafting some of the solution files. You know the ones - the ones that WSPBuilder hides away. I did try that tool some time ago, but had problems with certain complexities in solutions, so returned to my old ways.
Well, it's time to kick that habit and learn something new! So now that I am starting a major new project I am also trying out a new approach to my day-to-day SharePoint development. First change is to incorporate SPVisualDev from the very start, and I must say I am really impressed with the ease it offers in adding fields, content types and lists to features. It even makes adding resource files nice n'easy, so encourages me to build the features ready for localisation if required in future (I know, I know, "YAGNI", but given that the tool makes this capability easy I'm all for its inclusion).
Then I am using WSPBuilder to create the WSP files (though am disabling the "Cleanup" operation so I can still get to the manifest.xml and ddf files if necessary!).
So far so good. Now all I need is a tool to generate a batch file with the appropriate stsadm commands for deploying a set of WSP files, and I'll be "sweet as, bro" (it's a kiwi thing!)
I'll let you know what else I change for the better.
Must admit I have always developed from the point of view of creating a deployable solution first, and adding functionality to that solution as I go along. Means that when the functionality is working and tested then I have a package ready to ship. Rather that than developing the packaging as a final task, and then needing to retest the deployment outcomes.
And I like CONTROL over the solution, so I have been hand-crafting some of the solution files. You know the ones - the ones that WSPBuilder hides away. I did try that tool some time ago, but had problems with certain complexities in solutions, so returned to my old ways.
Well, it's time to kick that habit and learn something new! So now that I am starting a major new project I am also trying out a new approach to my day-to-day SharePoint development. First change is to incorporate SPVisualDev from the very start, and I must say I am really impressed with the ease it offers in adding fields, content types and lists to features. It even makes adding resource files nice n'easy, so encourages me to build the features ready for localisation if required in future (I know, I know, "YAGNI", but given that the tool makes this capability easy I'm all for its inclusion).
Then I am using WSPBuilder to create the WSP files (though am disabling the "Cleanup" operation so I can still get to the manifest.xml and ddf files if necessary!).
So far so good. Now all I need is a tool to generate a batch file with the appropriate stsadm commands for deploying a set of WSP files, and I'll be "sweet as, bro" (it's a kiwi thing!)
I'll let you know what else I change for the better.
Subscribe to:
Posts (Atom)