Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major Upgrade Features Planned to make this my Evernote replacement... #78

Open
jasondavis opened this issue Mar 12, 2016 · 2 comments
Open

Comments

@jasondavis
Copy link

Upgrades to Wikitten to make it my Evernote Replacement!

Below is my to modify the app to fit my own personal needs. If anyone has ideas, feel free the mention in the comments and I might implement them as well.

My goal is to remain a file, non-DB app for easy portability. However many of my upgrades below would benefit and open up more possibilities if I decided to switch to a database down the road.

Luckily there is SQLite which is a file based Database. SO I could easily use SQLite and still be a file based portable app! For now though I am going to not use a DB if I can.

Real Plugin System

  • I have a Plugin system that is exact clone of WordPress plugin system.
  • Has action hooks which can be ran in the code-base everywhere some sort of action happens.
  • plugin folder, reads the top comment block of plugin files to get the name, description, version, author, etc...
  • in the plugins, they can hook into the above action hooks to truly have a realy working plugin system that allows people the extend this beyond the imagination without touching the core code base! Right now the plugins folder has the PluginBin.php file and it is enabled in the config file manually and then it is manually called in the render.php file. With the new system, any plugin could hook into the render.php file without any manual hard coding names like it is now.

New Default Plugins that I have planned so far. Please do mention your ideas for other plugins!

Most of these plugins mentioned here can hook into the on-save action event or on the render action event. The embed plugins below might be best hooked in on the render action so that files saved outside of the app will also be processed. Something like the JS beatificastion might be better to run on save so that it doesnt have to run on every view! Really up to the user though.

Embed style plugins

These things might be called in the format of a short_code like WordPress uses. So when the file is parsed and a shortcode is detected it is replaced with the embed code for that plugin.

  • CodePen embed plugin to show embedded CodePens
  • JSFiddle embed plugin to show embedded JSFiddles
  • GitHub Gist embed plugin to show embedded GitHub Gists
  • YouTube Video embed plugin to show embedded Videos
  • SlideShare.net Slideshow Embed Plugin

Render plugins

  • JavaScript Beautification Plugin - can be a button or a setting in config to pass JS files though this to format them nicely.
  • CSSComb Sort CSS Properties Plugin - Button and/or config setting to pass CSS files thorugh CSSComb whichsorts CSS definition properties in a set uniform order.
  • images Optimization Plugin - are uploaded into the media manger mentioned below, pass them through an online service to compress/optimize the image before saving.
  • Format SQL Plugin Its a JavaScript library that formats SQL into clean readable syntax

Build File Type Render Mapping

The idea here is to have a list of file extensions and map each one to a render() function.

Right now the MarkDown file maps to render with the Markdown parser.

With this re-engineered and the plugin system, you would be able to add your own custom file types and render() functions for them. This opens up the door to many unique things.

Example....A new Book COllection file type might hold a collection of my programming books in a certain format and my render function could format these type of files to show in a nice tabular format with thumbnail image to the left, book data to the right and format it in a nice way to easily view the collection.

Basically allow you to create templates for different file types to show when viewing them. THe template would have placeholder variables and the render() function for your file type would parse the file to get the template var values and build the final output.

File CRUD Actions

Sidebar

  • Create Folder
  • Rename Folder
  • Delete Folder (if not empty, dialog to ask if child files in the folder should be deleted as well or if they should be removed to another folder first?)

Files

  • Create File
  • Delete File (show confirmation dialog. Also ask if revision/version copies should also be deleted i they exist?)
  • Rename a File
  • Move file to new folder dialog. Click a button to move a file which would then list all folder in a drop-down list and let you select one and on submit it would copy the file to the new location. (the history folder for file revision./versions would have a similar copy of the folder/file structure so will have to also copy the history versions of a file that is moved into its new folder too.)
  • Set another file as the current files Parent file.
    • If this is done, then this file will no longer show up in the sidebar in the list of files unless a switch is toggled to show hidden child files
    • This child file will also now show up on the parent file render page. Just like multiple files shown on a GitHub Gist page!
  • Each file will have the option of turning the file revision/versions on or off for that individual file.
  • Render PDF files in an embedded PDF viewer like Gmail and many other sites use.
  • If a folder has images, show images in a nice large modal window when clicked on and allow keyboard arrow navigation to view through all images in a folder at alarge scale quickly.

Media Manger

  • Just like the Media Manager Modal window in WordPress. It will allow you to biew and insert existing used files over and over> It will also allow you to upload files from computer and from remote URL.
  • On a MarkDown file you can simply click an insert image button or media manager button and the media manger modal window will open up and you can upload a new image or click to insert an existing used image into the document.
  • The files uploaded into Media Manger will be uploaded to a folder that is not shown in the sidebar.
  • When uploading a new file it will also have the option to Crop the image if you want to.

Other File Features

  • Make all files have a distinct view mode and edit mode. Right now only markdown files have a view and edit mode. Code files are always edit mode and I want them to have to click a button to go into edit mode on all files first!
  • Add MarkDown buttons like BBCode style button for quick click to format.
  • If it doesn't exist already, switch the Markdown parser with one that supports GitHub Flavored Markdown so that Tables can be used in Markdown docs.
  • Show Window onUnload Alert if you try to navigate away from the page with un-saved edits.

Multi-file in 1 support like GitHub Gist

  • add capability to embed multiple files into 1 files. Example 1 file could have markdown file and below it a code PHP file and below that a CSS file. The PHP and CSS file embed would then not show up as files in the file lists. Similar to how GitHub Gists can have multiple files in a single Gist. When showing a plugin or code project, often it makes more sense to have them all on 1 page instead of spread out.
    • Solution Idea 1) since it currently is 100% file based with no database. 1 idea to achieve this is to use a file based SQLite Database to store the file name and a parent filed to designate that a file is to belong to a parent file and then do not show any child files in the menu.
    • Solution Idea 2) Same as idea Simple User Login #1 but instead of a SQLite database, use a JSON file to s tore this info.

File Versions/Revisions with DIFF view

  • I really like the DIFF viewer you see on StackOverflow and WordPress used to compare versions of a file/record. The nice side by side DIFF view and Inline DIFF view.
  • Generally apps that do this store the content in a DB but to remain file based the idea is:
    • Anytime a file is saved, from within the apps editor. Save the file as a new version and move the previous file to a history folder.
    • So every save button click if there are changes, would create a new file and then copy/move the existing file to that history folder and would change the file name of the history version to include a DateTime time-stamp in the filename.
    • The DIFF viewer page would then have the capability to compare any 2 files for
      that file record and restore one as the "current".



If I use SQLite Database, it opens up all these possibilities down he road...

  • Store File record for each file that will hold:
    • ID - auto generated ID to use when modifying records and Index
    • File Name
    • File Path
    • File Size
    • File Type
    • create_on Date
    • modified_on Date
    • created_by - User_id of a user in the Users DB table who created the file
    • modified_by - User ID of user who made the last edit.
    • parent_file - If this file is to be shown on another parent files view page, its parent file ID will be here.
    • hide_from_menu - false by default but when a record gets a parent set, based on a setting in the app it will auto set this child file to be hidden from the menu and only show up inside the parent files view page.
    • revisions_on - turn on/off the Revision/Versions capability on a per file basis
    • max_revisions - set the max number of revision files to create. Once this number is reach and a new revision file is made, it will rotate the files deleting the oldest file first.
    • current_version - will be the ID of the current file. This allows an older version in the revisions to be restored and be the set file for this file event though it would have an older date and higher ID number than the most recent copy. (Word Press stores revision records in the same DB table as the post records which makes sense since they have the same exact columns and also mean they don't have to do any JOIN queries to get the versions and change versions. I am undecided on making a new Versions DB table or storing in the FIles table and having a type filed determine a version record vs a file record.)
    • record_type - file, version, image
    • deleted - soft delete.
  • Plugins DB Table
  • Settings table for app and also API for plugins to use it.
  • Could store a folder drag and drop sort order in the sidebar to DB table.
  • Could do a basic user authentication system with ACL and then set view and edit, delete, create permissions on a per user basis and on a ACL group basis. So you could enable/disable the CRUD functionality for a user group and on a per user basis. This could also be set on a per file or per folder basis.
  • Could do things like restrict access to certain files with a password or something similar. Would probably do something like encrypt the file and folder-names shown in the URL to prevent user from easily getting around the password system. SugarCRM makes there upload files only viewable after passing through a script so user can never know where they are saved. Also they encrypt the URL ID to view the file
  • Audit Log DB table - store every action by every user.
@georgesuba
Copy link

this looks really good.. is there any dev repo I can test it?

@dmayo2
Copy link

dmayo2 commented Apr 2, 2016

I'd like links being able to have a target:
[link](url){:target="_blank"}
The ruby kramdown supports this in their superset.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants