andrewraycode / ray-frame Goto Github PK

Being able to drag an image from your browser into a page, have it upload to the right folder, specify the thumbnail size by dragging resize handles, and auto-generating the thumbnail from it. aw yeah.

Need a form to upload files. If it is an image, this form should auto generate thumbnails at the bare minimum. Configuring thumbnail size is not a priority for v0.1, as long as it does something with them.

Inline editing needs to have a defined system. Specifically

• getting field values
• setting field values
• initializing / saving inline edits
• research into rich content editor (Aloha? homegrown?)

Template should handle if / else tags, and render them as async function calls. should handle falsey statements

When inline editing a title, the URL should be updated as well to reflect the change. Maybe add to the wishlist, checking for conflicts on update.

A way to access it, layout defined, configuration options

Need to be able to

• add user
• delete user (not original admin account)
• modify permissions of users

Needs to be at an interface accessible at a specific URL, or tied into the main management interface for media

A way for users to log in. Simple form living at admin access URL is acceptable.

Look into using html comments as markers and jQuery's nextuntil to grab elements in that area.

add these two fields to elements, and make default sort for lists be creationdate. update lasteditdate on edit.

create bar along bottom - toolbar for editing pages. Will flesh out with more ideas - needs save / cancel at very least I think... link to admin screen...?

There must be some way to insert media into a page. This is for both image areas and content areas. Metadata most likely should be stored in couch. folder browser?

if you do

this.append('moo');
this.append('fluff');

it becomes

str += moo;
str += fluff;

It should become str += moo + fluff;

With a getbuffer method that will take any unappened shit and fix it

go all the way through in the front end, insert, give title, open new page.

through usage determine which is better, make title > go to automatically, make title > let it be clickable ... just go to the new created thing and not show the inline creation?

I'm labeling this as 0.1 because it should be a part of the core functionality of ray frame. fields should be versioned, most likely by storing their text content in an array. media should not be versioned. I don't care if it's viewable on the front end. I just want:

• store the history of any edited field on an item so that it can be retrieved at a later time

Template parser is not very robust. Make sure it can handle:

• multiple includes
• multiple wrapped by levels
• multiple level deep block replacement
• multiple level deep list rendering

right now it just does plips. fine and dandy, but needs sort=user

If you delete a page or rename a page, turn it into a pointer to the new page. define redirect handler / default template hook

needs to handle {{list:sort=name,descending}} or similar, or a custom sort function {{list:sort=userFunc}}

aspects to this:

• newly created items need to be private by default until explicitly made public
• couch views need to be role based, so that things like paginations and counts look differently to different users.
• am I forgetting something?

some polish (not Polish)

Implement it if it makes sense to do so!

make sure cache functions can take page numbers, and define results per page in templates, and store those.

for example

{{list:perpage=20}}

hit at /pageWithList?page=3

should pass to the cache function {plip: list, perpage: 20, page:3} and return the right results

If you include {{bobsag}} and it doesn't exist - what happens? Can you still edit it in admin mode? Do you show nothing? What about fields wrapped in {% if bobsag %} ? Include a list of hidden fields to potentially edit?

Users need to be stored / loaded from couchdb. passwords need to be stored encrypted.

Ready for 1.0. Includes static media, tag system, form of authorship.

Implement django {% block %} tags, which are overwritable by child templates

Instead of

{{blogs:list:view=link.html:type=blog:sort=user}}

It would be nice to do

{{blogs::userList}}

plips: {
userList: {
view: 'link.html',
type; 'blog',
sort: 'user'
}
}

template tag url should output page URL correctly

if a value comes from local it shouldn't be editable

data.locals[var] || data[var] ? 'edit' + data[var] + '/edit' ? ''

brings up points:

• if it ends up in neither, do we assume editable, not editable?
• do we only assume variables are editable if they have :something with them?
• I forget the third point

Obviously there is conditional logic in a template. Do you pass all the data to the front end and re-render it client side? Can you specifically re-render one template? Are others affected? Refresh the whole page? AJAX in the whole page? HwaH?