EBE: Configurable links on bottom of every post

Topics: Enhanced Blog Edition
Coordinator
May 26, 2007 at 6:17 PM
Has anyone thought about or already implemented an extensible way to define all of the various "bookmark it with del.icio.us | add to windows live favorites | digg it | reddit" links at the bottom of every post, so each one can be enabled/disabled?
Developer
May 27, 2007 at 11:35 PM
This is already the case for my implementation of these links. Each is a separate list column, so they can be deleted from the list or removed from the list view as necessary (we could document these very simple steps or provide a control from the settings page for this).


lawrenceliu wrote:
Has anyone thought about or already implemented an extensible way to define all of the various "bookmark it with del.icio.us | add to windows live favorites | digg it | reddit" links at the bottom of every post, so each one can be enabled/disabled?

Developer
May 29, 2007 at 6:56 PM
My suggestion would be this...

Create a list with a row per link you wish to add. They are all generally formatted URLs with some information about the post or blog. The list would contain images, text, anything we would need to display the links. The links themselves would be formatted with 'tokens' so that we could replace them with the required information when the page is rendered....

http://del.icio.us/post?url={url}

We could define a number of tokens (any we can think of) and new URLs could easily be built. We could then have a column on the List which enables/disables the links. This list could then be rendered with on of the current EBE XSL controls and so we only need to write thr XSL.

We just need a list of the links

Developer
Jun 5, 2007 at 10:32 PM
I'd still like the notion of defining custom columns on Posts and Comments - I'm not sure I want users to have to lose that avenue of customization in favor of the modular theme framework because I think we can have both. After I install the wsp, one thing I might want to do is add a "Related Posts" column on Posts (a multi-valued lookup) and then add some extra fields for commenters to include additional information about themselves when adding comments.

In addition, "Links to this Post" is a custom field that needs to be shown in order to show the trackbacks (and pingbacks) received.

Wouldn't it be relatively straightforward to enumerate and display custom fields defined on Posts and Comments? I haven't had a chance to look into it, but I would think there is probably an object model method to get the rendered HTML for a field (might have to be XHTML-corrected, though).

If that can be set up, then users can define custom fields and I can keep the little post links as list columns. Then, I can provide a web part that will allow you to easily add your own formatted "linklets" (the web part would add computed columns to the Posts list, and potentially other lists as well).


TheKid wrote:
My suggestion would be this...

Create a list with a row per link you wish to add. They are all generally formatted URLs with some information about the post or blog. The list would contain images, text, anything we would need to display the links. The links themselves would be formatted with 'tokens' so that we could replace them with the required information when the page is rendered....

http://del.icio.us/post?url={url}

We could define a number of tokens (any we can think of) and new URLs could easily be built. We could then have a column on the List which enables/disables the links. This list could then be rendered with on of the current EBE XSL controls and so we only need to write thr XSL.

We just need a list of the links



Developer
Jun 5, 2007 at 11:28 PM
Unfortunately WebParts and the MTF are pretty much incompatible. The webpart framework outputs far too much custom HTML (TABLEs etc) which cannot be removed. When producing an XHTML DIV based layout you don't really want to have to deal with spurious TABLEs. This would make creating additional Themes much more complicated. Thats not to say they cannot be used...you can definitly add them to a page, but your theme would have to be designed (CSS) to account for them (TABLES).

If you can produce a standard ASP.Net control which produces good HTML (or preferably XML) then that would work...I'm not sure of the benefit of creating a WebPart if you are not using the whole WebPart framework?

The problem with custom columns is the URL you are using to pass to del.ico.us...

A link to del.ico.us may look like
<a href="http://del.icio.us/post?url=http://cks.wssblogs.com/archive/2007/06/05/this-is-a-post-from-livewriter.aspx>Del.icio.us</a>

Using a custom column I can't see how you can generate the re-written URL to the post??

It is also always worth bearing in mind that any Lookup columns are generally going to present a problem when using Queries to retireve data. They work for views (I believe they are created somewhere in the COM API or SQL) but SPSiteDataQuery does not like them. Also I am pretty sure there isn't an API call to get a column rendered as HTML as defined by CAML. There is a GetValueAsHtml (or similar) on a field, but I have never seen it called on any of the custom field controls/columns I have created. I would be very interested if anyone knows different!







nmitha wrote:
I'd still like the notion of defining custom columns on Posts and Comments - I'm not sure I want users to have to lose that avenue of customization in favor of the modular theme framework because I think we can have both. After I install the wsp, one thing I might want to do is add a "Related Posts" column on Posts (a multi-valued lookup) and then add some extra fields for commenters to include additional information about themselves when adding comments.

In addition, "Links to this Post" is a custom field that needs to be shown in order to show the trackbacks (and pingbacks) received.

Wouldn't it be relatively straightforward to enumerate and display custom fields defined on Posts and Comments? I haven't had a chance to look into it, but I would think there is probably an object model method to get the rendered HTML for a field (might have to be XHTML-corrected, though).

If that can be set up, then users can define custom fields and I can keep the little post links as list columns. Then, I can provide a web part that will allow you to easily add your own formatted "linklets" (the web part would add computed columns to the Posts list, and potentially other lists as well).


TheKid wrote:
My suggestion would be this...

Create a list with a row per link you wish to add. They are all generally formatted URLs with some information about the post or blog. The list would contain images, text, anything we would need to display the links. The links themselves would be formatted with 'tokens' so that we could replace them with the required information when the page is rendered....

http://del.icio.us/post?url={url}

We could define a number of tokens (any we can think of) and new URLs could easily be built. We could then have a column on the List which enables/disables the links. This list could then be rendered with on of the current EBE XSL controls and so we only need to write thr XSL.

We just need a list of the links




Developer
Jun 6, 2007 at 12:21 AM
I'm not suggesting having a custom web part to display additional columns.. I was wondering whether it would be possible for you to iterate through and render user-defined field values using GetValueAsHtml in your XHTML?

With regards to generating the re-written URL in my computed column... this would only be possible if the URL is stored in a column on the Posts list. However, I personally would like to see backwards-compatibility with the existing SharePoint URLs. Here are my reasons:
1. A lot of users would not want to break links after having used the WSS blog for a while and then later downloading and activating EBE.
2. There are just far too many places where SharePoint will use the standard item URL, and it would be ridiculous to attempt to override this behaviour in every place. You mentioned RSS, but there are other circumstances as well including alert notifications. As another example, we use the content by query web part in MOSS to display an aggregate view of several blog sub-sites.
Consequently, I think navigating to Posts.aspx?ID=1 should redirect to the friendly URL showing the themed view (unless there is an override querystring parameter, like "&NoRedirect=true" - that way you can always prove it's still SharePoint :)


TheKid wrote:
Unfortunately WebParts and the MTF are pretty much incompatible. The webpart framework outputs far too much custom HTML (TABLEs etc) which cannot be removed. When producing an XHTML DIV based layout you don't really want to have to deal with spurious TABLEs. This would make creating additional Themes much more complicated. Thats not to say they cannot be used...you can definitly add them to a page, but your theme would have to be designed (CSS) to account for them (TABLES).

If you can produce a standard ASP.Net control which produces good HTML (or preferably XML) then that would work...I'm not sure of the benefit of creating a WebPart if you are not using the whole WebPart framework?

The problem with custom columns is the URL you are using to pass to del.ico.us...

A link to del.ico.us may look like
<a href="http://del.icio.us/post?url=http://cks.wssblogs.com/archive/2007/06/05/this-is-a-post-from-livewriter.aspx>Del.icio.us</a>

Using a custom column I can't see how you can generate the re-written URL to the post??

It is also always worth bearing in mind that any Lookup columns are generally going to present a problem when using Queries to retireve data. They work for views (I believe they are created somewhere in the COM API or SQL) but SPSiteDataQuery does not like them. Also I am pretty sure there isn't an API call to get a column rendered as HTML as defined by CAML. There is a GetValueAsHtml (or similar) on a field, but I have never seen it called on any of the custom field controls/columns I have created. I would be very interested if anyone knows different!







nmitha wrote:
I'd still like the notion of defining custom columns on Posts and Comments - I'm not sure I want users to have to lose that avenue of customization in favor of the modular theme framework because I think we can have both. After I install the wsp, one thing I might want to do is add a "Related Posts" column on Posts (a multi-valued lookup) and then add some extra fields for commenters to include additional information about themselves when adding comments.

In addition, "Links to this Post" is a custom field that needs to be shown in order to show the trackbacks (and pingbacks) received.

Wouldn't it be relatively straightforward to enumerate and display custom fields defined on Posts and Comments? I haven't had a chance to look into it, but I would think there is probably an object model method to get the rendered HTML for a field (might have to be XHTML-corrected, though).

If that can be set up, then users can define custom fields and I can keep the little post links as list columns. Then, I can provide a web part that will allow you to easily add your own formatted "linklets" (the web part would add computed columns to the Posts list, and potentially other lists as well).


TheKid wrote:
My suggestion would be this...

Create a list with a row per link you wish to add. They are all generally formatted URLs with some information about the post or blog. The list would contain images, text, anything we would need to display the links. The links themselves would be formatted with 'tokens' so that we could replace them with the required information when the page is rendered....

http://del.icio.us/post?url={url}

We could define a number of tokens (any we can think of) and new URLs could easily be built. We could then have a column on the List which enables/disables the links. This list could then be rendered with on of the current EBE XSL controls and so we only need to write thr XSL.

We just need a list of the links





Developer
Jun 6, 2007 at 12:38 AM
1. That is kind of the point. I will migrate from community server, other from DasBlog and others will upgrade from an existing WSS blog. We need to be able to keep all the URLs working. The current friendly URLs are for CS, but we should create providers (eventually) for all blogs we want to migrate. This may mean a custom column is out. The SharePoint URLs should always work...even if it is a re-direct.

2. True...but its not impossible...alerts would be relatively easy. This, I suppose, depends on where you are using the blogs...alerts are not a standard blog feature as most people would rely on WSS.

Vince