Battler45
commented
4 years ago Ben,
This is to update you on current work progress. I have implemented most of the requirements. I am working on integrating FCKEditor in blog post page.
There is one query regarding "Post Date" control. My understanding is to implement control similar to control on site-analytics page. Please note that that control only supports date selection. If time part is also to be captured than I will need to modify that control. Please let me know your thoughts on this.
Thanks Posted by Shah Vihang(unfuddle username: vihang)
Vihang,
I've prepared a mockup of the form that you can use to implement the Add / Edit Blog Post functionality on the site:
http://client.sierrainteractivedev.com/blog-post-form.htm
Some of the features of this form will be straightforward, but there are a number of details that will need to be taken into account. In implementing this functionality, you may want to review the functionality of the blog post editor on the current admin site. Go to:
http://client.sierrainteractive.com
And login using:
Sitename: joehaydenrealtor.com Username: joe Password: g0ldr3c0rd
Please bear in mind that this grants access to a live site, and so please refrain from making any changes to content (or, at least, undo them once they are done). To get to the Blog manager, click the Manage Blog link. If you need to add a new post to review the functionality, that is fine, as long as you remove it within 5-10 minutes after creating it. There are some differences between the functionality of the old system and what you will be implementing, but there are also quite a few similarities.
1 -- The Post Title field corresponds to the PostTitle field of the SICM_BlogPosts table
2 -- The Post Filename field corresponds to the PostFilename field of the SICM_BlogPosts table
3 -- The Category drop-down pulls from the SICM_BlogCategories link. When you click this drop-down, you'll notice a "New Category..." option. When selected, this should pop-up an overlay window (as on the current site) which prompts the user for the name of the new category and also for the filename.
On tab, the programming should automatically convert the users category name into a filename by stripping out all spaces and special characters, transforming all characters to lowercase, and replacing spaces with hyphens. The user will still have the ability to edit the filename, but when focus is removed from the field, the programming should automatically validate the user's input to the above standard.
The filename is used as part of the URL on the front-end blog when viewing posts from that particular category, so the filename should also be validated against other filenames from that blog to ensure that there are no exact duplicates (on submit). On successful submission of the New Category form, the new category name should dynamically be added to the Category drop-down and selected.
4 -- The Tags drop-down pulls from the SICM_BlogTags table. When the user selects the "New Tag..." option, an overlay should appear with the title "New Tag" requesting the name of the new tag (as on the current site). On submit, the user's input should be validated to make sure it is not a duplicate. On success, the modal dialog should close, and the tag should be linked to the post and displayed as in the example in the mockup. This functionality resembles the "Label" functionality in GMail, where you can assign multiple labels to a single email message.
When the user clicks an X next to any assigned tag, the tag disappears and the database relationship between the tag and blog post are removed.
It's important to note that when the user initially arrives at this page to add a new blog post, the Tags drop-down should be disabled. This is because the new post will not yet have a database ID, and so it would not yet be possible to associate tags with the post.
It is only after the user enters a post title and filename, and selects a category, and (optionally) enters meta-tags for the post, that the Tags drop-down should become enabled. (And, of course, it is always enabled in cases where the user is editing an existing post.)
5 -- The Meta-Tags textareas pull from the SICM_BlogMetaTags table.
6 -- You'll notice that in the right column there are two separate gray boxes with the title "Post Overview." The top box is an example of what the user should see when editing a post; the bottom box is an example of what the user should see when adding a new post (on initial page load). So, of course, there would only be one of these boxes visible in the finished page.
I would like the gray box to follow the user down the page as he scrolls down, so that it always remains visible and well-positioned for the user throughout the editing process. This means that the Save and Cancel buttons will be available at any time. I know there are some jQuery plugins / scripts which create an animated effect for accomplishing this, and if you can find one that is easy to implement, that's great. Otherwise, using CSS and fixed-positioning would also be fine if that will work.
For new posts, please default the Status to On-Hold, and the date and time to the current date and time. Clicking the date or the arrow next to it should bring up the same date / time picker that Vihar has already implemented on the task functionality on the Lead Detail page.
7 -- For new posts, when the user completes Title, Filename, and Category and clicks the Save button, a "slide down" message should appear from the top of the screen indicating that the post has been created successfully (blue text on white background as Vihar has implemented on other pages on the site), and the user should be scrolled down to the bottom of the form, where a text-editor window should dynamically be made to appear.
To get a sense of how this should work, please do go ahead and try adding a new post on the above website.
On the current admin area, I have been using the open source FCK editor to provide the editor functionality, and I think we should stick with that. They have a new version (the CK Editor) but in testing, I have not been happy with the way it automatically rewrited HTML entered into the editor window, and so I would prefer to stick with version 2.6.4 as on the current site (or a newer one in that line, if available).
If you view source on the Edit Blog Post page on the current admin area, you'll see quite a bit of javascript included in-line with the page. It is not pretty and not well-documented, but it should give you a basic idea of how to go about implementing this functionality. The FCK editor does include methods for dynamically creating and inserting editor windows on the fly. I've zipped up and attached the fckeditor files from the current site for you to use on the new site if you want to do that, but feel free to adapt or change as necessary.
You will definitely need to make some modifications to the Image Browser functionality, as it is currently configured to use the Classic ASP uploader plugin, and you will want to change this to the .NET uploader plugin (see http://ckeditor.com/download -- it looks like for FCK editor 2.6.4 there is an ASP.Net control which should simplify the implementation for you.)
8 -- In the right-column Post Overview box for editing (the top one) you'll also notice that there is an "Auto-Saved..." message. If you can figure out how to implement this type of functionality without too much trouble, please do so, but please don't take too much time for that if it proves to be very difficult. At this point it is more important to me to keep moving forward as quickly as we can than to get snagged on something like that if it ends up taking quite a bit of time.
I think that's it for now -- I'm sure you'll have questions. Please let me know if you do.
Thanks.
Posted by Peskoe Ben(unfuddle username: bpeskoe)