A new BlogEngine.Net extension

Topics: Themes
Sep 6, 2007 at 11:57 PM
Edited Sep 7, 2007 at 12:17 AM
Mads Kristensen has done it again. He wrote an extension that takes what is dubbed "autolinks". This page is a demonstration of how it works. Here are some of my autolinks

You can see it work at http://www.romanclarkson.us.

The links are rendered by typing in BE, MADS, HAACKED, sz, lmc, kjs, sz

This extension will also include xfn tag support. You can see the data layout in the autolinks.xml file.
I will work on an Admin interface in the future.
Sep 7, 2007 at 4:09 AM
Well this is what I contributed as a patch (different looking code, but exact concept) that was declined. BUT this is not a good solution because if you look at your RSS feed it has this:
<p> lmc; kjs; BE; HAACKED; sz </p>

The post.serving event is inadequate for this purpose. It really needs to be in a new post.saving event that allows you to actually put the link in the xml file (or database).

I actually have this feature on my blog in the add_entry page. If you look at my submission you will see that I already had an admin page for my setup.

http://www.ckurl.com/be_change.zip
- Clarence
Sep 7, 2007 at 2:38 PM
I know I jumped the gun with a post, on my site I say that it is in testing. We are using these types of extensions to determine what items need to be manipulated before saving and before rendering. A thought with this version is that a user may change their website in the future, email, xfn, whatever. My thought was that the blog needs to point to the current information/location to keep it relevent.

It seems to me that we should have some mechanism in the syndication that would use the extensions to manipulate the output.

Again, it comes back to...... Save now and render as is, or save as is and render later? Thoughts?



ckincincy wrote:
Well this is what I contributed as a patch (different looking code, but exact concept) that was declined. BUT this is not a good solution because if you look at your RSS feed it has this:
<p> lmc; kjs; BE; HAACKED; sz </p>

The post.serving event is inadequate for this purpose. It really needs to be in a new post.saving event that allows you to actually put the link in the xml file (or database).

I actually have this feature on my blog in the add_entry page. If you look at my submission you will see that I already had an admin page for my setup.

http://www.ckurl.com/be_change.zip
- Clarence

Sep 7, 2007 at 4:06 PM
I think you save now and render as is, unless an extension a user installs does something to the rendering.

I'd prefer to save as is, because "my church" may be different today then it was when I wrote a post 2 years ago... and it should still link to the correct church and not the new church.
Sep 7, 2007 at 7:12 PM
Gotcha, but I would use a new shortcut word for each entity. That way you could have your "my church" render with the correct information. Perhaps it changes its name or web address. I would want entities related to me to remain updated to keep my blog relevent and current, not necessarily a historical record. The other thing that is being tested in the autolinks is xfn tags. A sweetheart now could be, well use your imagination, something else tomorrow. I would not want my site to indexed with this person as a sweetheart everytime when I would rather have her as a, ahem, contact.


ckincincy wrote:
I think you save now and render as is, unless an extension a user installs does something to the rendering.

I'd prefer to save as is, because "my church" may be different today then it was when I wrote a post 2 years ago... and it should still link to the correct church and not the new church.

Sep 7, 2007 at 8:07 PM
But a Blog is just that, a historical record....
Sep 7, 2007 at 11:01 PM
Not for me really. I never blogged until I found BlogEngine.Net. My goal was to publish articles/blog entries for instructional purposes. Some how, I now develop for it. Go figure. Regardless of the use of the blog, I think that the OnSaving and OnServing events will allow all of us to do what we want to do.



ckincincy wrote:
But a Blog is just that, a historical record....

Sep 8, 2007 at 2:46 PM
Okay, okay, you're both right. :D

This is why WordPress uses comments to handle this, for example, the 'More' links, which are handled by way of <!--More--> (IIRC). This is also why I recommend(ed) using a similar comment system to handle AdSense addition (on a per-post basis).

As for when it makes sense to do the rewrite, I should hope it's when the page is being served. While it does mean that the code has to be looked over every time it's served (assuming a cache system isn't in place), it does mean that you can make a modification in one place, and it'll be served in every necessary place, which is the benefit of using these. Otherwise, you're defeating the purpose of this.

You also have potential issues, if you do a replace when saving, if the content that will be added may be corrupted, in some way, by the editor(s).

For example, using the default installation of BlogEngine.NET (with the default editor of ... TinyMCE, I'm unable to add certain JavaScript code to my posts.

Now, assuming I setup some kind of replace, if it's inserted into the post at save, instead of at serving, my JS code is gone (either immediately, or the next time I edit the file).

Finally, if the serving fails, for whatever reason, with comments, there's no real issue. However, with any other method (using brackets, whatever) you have the potential for display issues (as was pointed out with the feed issue).

As for the historical issue, I'm with Roman - primarily I post articles. However, the use of this functionality (replace code with other code inputted elsewhere) should be used for things which should be the same across all instances. If I write a post about my girlfriend, I'll just put her name in the post. However, if I want to put my address, I may want to have my current address (and therefore use the replace code). Am I listing my address so that people can send me money, or listing it for historical purposes? I currently live at, versus send money to ...

And, assuming there's flexibility, there's nothing to stop me from just setting up multiples per. Girlfriend2007, Girlfriend2005 ... (or depending upon how fast you go through them ...)

In conclusion, use comments.

~James
Sep 8, 2007 at 3:50 PM
James, you are a thinker "Girlfriend2007, Girlfriend2005 " ;D

I think the result will be two versions of the autolinks extension. There will be only data file and one class file. The user will have the option to use the OnSaving or OnServing, they just may have to change which event is being raised.

I am wondering if manipulating the rendering is this important, shouldn't the Syndication have a something like an OnServing event as well.

Otherwise, the autolinks being rendered with OnServing will always render wrong on the Syndication. I am sure everyone will agree that the Syndication features cannot be hardcoded to handle autolinks.

So.....
OnSaving and RSS == Good || OnServing and RSS == Hook into the Syndication with a render event.


Sep 8, 2007 at 6:09 PM
Edited Sep 8, 2007 at 6:10 PM
{"Keeping with this line of thought (so, ignoring whether we're going in the right direction or not), I suppose you could have some options like that. But, there would be a couple others you might need, because of the way the RSS feed is created (based on all of the text, and not just on a blurb, or part of the article/post).

Component name
Find text
Replace text
OnSaving or OnServing
Replace in feed?

Examples:

Component name: Add adsense code
Find text: <!--AdSense_Square1-->
Replace text: insert adsense code here
OnSaving or OnServing: OnServing = checked
Replace in feed? No.

So, every instance of <!--AdSense_Square1--> in posts would be replaced by the adsense code, when it's viewed on the site. However, the comment would be served when editing the post or when viewing it through RSS.

Component name: Add standard disclaimer language
Find text: <!--Disclaimer-->
Replace text: This content is copyright blah blah blah.
OnSaving or OnServing: OnSaving = checked (? I'd do OnServing, but I can't think of a good OnSaving block of text ...)
Replace in feed? n/a (Since OnSaving is checked, this is no longer an option.)

So, every instance of <!--Disclaimer--> in posts would be replaced by this text. Really, as I was somewhat suggesting before, this is the same as basically allowing users to create buttons which would allow them to enter standard text into the editor. I'm having a hard time of thinking of what language I'd personally use, but ... maybe a listing of standard links? or biographical information that won't change that often? I guess some could put their loved one's name(s) into components, but instead of adding <!--Girlfriend_2007-->, I think it would be easier to just type in the name - it's not like it's that long, and hopefully you remember the name(s) ...

But, assuming the link wouldn't change that often, I guess you could use something like this for links: <!--Link_BlogEngineMain-->, <!--Link_Google-->, ...

However, there's probably an easier way to handle external links, that would also enable tracking of external links ... Since Mads has already said that he'd like internal links to be without the domain name, there's already the possibility of doing a search for href="(http(s)?:)|(ftp:) (in no way a complete RE) when serving files to automatically start doing this ...

~James"}
Sep 13, 2007 at 3:43 AM
James,

I think Mads extended the OnServing event so that it now wires up from post/pages/rss feeds.

Here the rss should do the exact same thing that any extension does that calls the OnServing. Then there shouldn't need to be ANY additional work. Am I getting this right? The RSS raises an OnServing, every class that has the Extension attribute would be ran just like the others? Ne pas?
Sep 13, 2007 at 11:55 PM
I'll try posting this again (seems it didn't post this morning):

That's good for me, and I think that'll make most people happy.

The only remaining item from this thread is an 'OnSaving' event suggested by ckincincy.

So, will extensions be able to influence the admin interface at all? (Adding new tabs, new options, etcetera.)
Sep 14, 2007 at 12:13 AM
OnSaving is already done by Mads I think. It should be in the current source.

I have thought about this one. I think we could do something really cool and really simple.

Old Idea: There is talk about implementing a "widgets" on the site, drag, drop, move, yada yada. If there is something like that, each widget would have its own dropdown "menu" (if you are in the appropriate role) that will let you edit the widget by selecting something like "Settings". Then we would inject the defined widget's web user control into the page just, just like a regular page, and that would be it. So you could have a weather gadget. When you are logged in to the site, you mouse over the title of the widget, see the menu, select settings, and see only your web user control.

New Idea: The more I think about it, wouldn't be cool if you clicked on a link on the widget somewhere that said settings (you have to be an admin). Then it would take you to the admin pages that has ONE tab titled with you widgets name. Then in the gray matter in the widget management page, you would have your widget's defined .ascx. This would keep the administration simple, you don't have to add large number of items to the tabs, etc. When you click on the Save you would be returned to the page that you just left. All of the settings applied, etc.

There would be two Interfaces, IWidgetDisplay and IWidgetSettings. This way you would only ever need one .ascx for the widget to work.

There would have to be a decision on how to save where widgets are and how to place them dynamically on the site. Some simple version of webparts, webzones, etc. I would recommend we use a personalization role provider, simple, clean and straight to the point.

Still more to think about.
Sep 14, 2007 at 4:54 AM
Last I checked the post.saving event was not complete, it was missing an actual eventargs for it (or something like that). I've been too busy and sick to finish adding it to it.

- Clarence
Sep 16, 2007 at 4:55 PM
OnServing doesn't work in RSS due to this bug I psoted:

http://www.codeplex.com/blogengine/WorkItem/View.aspx?WorkItemId=3331

It's a simple fix and I've included the line that needs changing in the bug.
Coordinator
Sep 16, 2007 at 5:59 PM
That has been fixed a week ago or so and can be found in the latest change set. However, the syndication will be rewritten to utilize the IPublishable interface but the OnServing event will still work