h1. Create yet another publishing tool - Jan 2015 A January 2015 project. Simple blog or note-taking web app. Uses: * Nginx for the web server * Node.js for the "client" code on the server * API-based ** possibly create the initial API code in Perl ** then create the API code in Node.js * use the Express framework for Node.js * use Handlebars for templating * use CouchDB for the data store * use Redis as the caching server This will be a simpler app than Grebe. * account creation and the login procedure will not use a password * use only Markdown as the formatting markup (node.js showdown) * two types of posts: articles and notes * notes will function like in the Grebe app with no char limits ** if no title, then a note. with title, then article. * the home page will look like the stream view when logged into the Junco app with notes and articles displayed * only the first 200 to 300 chars for notes and articles will be displayed in the stream view * little text area box displayed at the top of the stream view when logged in, which can be used for either notes or articles * click post link for a larger textarea box that can also used for both notes and articles * no fancy blog-like display options for articles like in Junco with the blog_username tag and like with the default view for Grebe * simplify CSS ** no homepage banner image ** borrow header and nav ideas from Grebe * **ability to display articles/notes/entire stream for a user??** * it will be multi-user * do not put the delete/undelete functions on the stream display for logged-in users ** move delete/undelete to the article page * will have a search function * Do NOT include the following features: ** related articles ** view article source ** hashtags auto-linked and counts stored in separate view * login will be done only through sending a link with mailgun h2. Content Description Are multiple types offered? article, draft, note. With the way Grebe works, a note is a draft, since both are not displayed on the front page. The only diffs are the draft has an official title line and the draft=yes command while a note has neither. So an article could be a "draft" by simply remaining as a post with no official title line, which is created with either the Markdown down single pound sign or the Textile h1. command. *_id* : either a generated five-character alpha ID or the slug/URI title *type* : post *title* : works like Grebe -slug- : (uri_title in my previous apps) ex: this-is-a-test - not needed if the above _id field is based upon the URI title -format- : markdown, textile, or whatever [not needed for now] *markup* : the entire original text, including title line, power commands, etc. *html* : the body of the post to display. the title line is not included here *text_intro* : like the stream page in my Junco app where the first x-number of chars is included in the display after the HTML tags have been removed. *more_text_exists*: true or false. if the total body text is greater than X-number of chars, and it requires the "more" link on the stream home page. -html_intro- : new field for me. if the "more." command is used, then the HTML body text of the post that precedes the more. command is stored on this field. [don't use for now.] -tags- : ex tags: ["nature", "bird", "home"] - (not right now) *post_type* : article (with a title), note (no title) or reply *author* : do I need an author_id?? not right now. *created_at* : 2009/02/17 21:13:39 *updated_at* : 2009/02/17 21:13:39 *reading_time* : in minutes ?? these two for both created and modified?? maybe not now -yr_mon_day- : [2015, 01, 30] -hr_min_sec- : [14, 39, 22] -post_digest- : is this still needed? i don't think so. use the couchdb _rev *post_status* : public, deleted ( ?? private, draft, old version ??) -parent_id- : for versioning and replying to posts h2. User Description *_id* : either the username or an auto-gen char code *type* : user *user_name* : *password* : *email* : *created_date* : *user_status* : (o) open, (d) deleted *desc_markup* : *desc_format* : *user_digest* : *orig_email* : *session_id* : IS THIS NEEDED? - default '0', -- send in cookie, maintain login - not needed if allowing user to remain logged in through multiple devices at the same time, especially since a session_id doc_type will be used. Since this is JSON, this value could be a hash, and I would not need the session_id doc_type. It could be: code.{ "session_ids" : [ { "id" : "aasdfjkioasdfjo", "created" : "2015-01-14 14:54:22", "status" : "o" } { "id" : "askasdfieiedfjo", "created" : "2015-01-13 23:12:05", "status" : "o" } ] } code.. *login_link_status* : (o) open, (p) pending, (d) deleted h2. Session IDs Description *_id* : this will probably be the session_id which has SQL table info of: varchar(255) not null default '0', -- send in cookie, maintain login *type* : session_id *user_id* or *user_name* : *created_date* : *session_status* : o open, d deleted #scaup - #blogging - #todo