Improvements Discussion


(Danny) #1

I want to use this topic to discuss some feature suggestions I had with the community. This post may sound a bit ranty but trust me it is not meant to be. I just want to voice some of the annoyances I had with the framework so far and some feature suggestions that arise from them.

Node Controllers and ‘out-of-the-box’ index views

After using PT for the past week I really wish nodes would behave more like Rails framework scaffolds in that they have:

  • dedicated controllers (that inherit from PushType) allowing for a more conventional way to route, pass parameters and make variables available in specific views. I mean how do you even link to an index node view whilst passing it a search query that narrows down the items displayed in that view. Think Article-Node and a search parameter filtering out non-matches. This can be done easily in rails in the controller action. Lack of a controller makes this impossible.
  • models that allow for relationships with other models (and that use Rails belongs_to/has_many keywords to create relations in both directions). Why does PushType use GUIDs? It breaks compatibility with other non-PushType models,
  • as well as views (in addition to what is currently the show view equivalent). An index view at the very least would be extremely useful and would make more sense from a user point of view. It makes no sense to want multiple ArticleList nodes (which serves an an index view) but the “New ArticleList” button is always there ready to be (mistakenly) clicked.

Reusable Forms

PT’s forms are very easy to use and user friendly. With the every increasing number of field types and community contributed custom fields it would be really cool if PT’s forms could somehow be reused in the front end, via a domain specific form builder with a PushType specific DSL.

Built in organisational nodes (e.g. Folder or Category nodes)

How about built-in category/folder nodes that allow users to organize content graphically without having to create a category/folder/whatever node.rb file. This would be useful to organize the backend a bit

Backend redesign

Speaking of the backend, I would prefer if the backend was structured like ActiveAdmin in that different Nodes (for example, Article, Category etc.) get their own menu item and section in the PT backend, rather than listing everything in one communal table with all node types in the same list.
ActiveAdmin Backend

The current backend gets very confusing when there are different nodetypes that are only there to organize content (eg. List nodes that create essentially index views and categories which are used as select options for other nodes)


(Aaron Russell) #2

Hey @danobot thanks for this. This kind of feedback is super useful - I appreciate you taking the time to post this.

Quite a lot to go through, I’ll just try and tackle things one by one…

Dedicated controllers

For clarity I’ve moved this discussion to it’s own thread:

Node models with relationships

This is quite a complex topic with lots of possible scenarios. You can use the relationship field:

# In your node class
field :widget_ids, :relation

# Then from a node instance
@node.widgets.all

However, this doesn’t create the reverse relationship from the Widget class. You need to define that yourself (although come to think of this, we could dynamically define this):

class Widget
  def nodes
    @nodes ||= Article.where(["field_store->>'widget_ids' ?| ARRAY[:id]", { id: id })
  end
end

If you wanted to use Rails’ has_many / belongs_to methods, the GUID isn’t a problem - you just need to use the UUID data type in your migration instead of Integer. Eg:

def change
  add_column :widgets, :article_id, :uuid
end

So a Node has_many Widgets relationship will work fine. But doing things this way won’t create the field in the admin UI when editing your models. It all depends what you’re looking to do. It’s a complex topic and I’m sure PushType can do better here.

Reusable forms

Again, not 100% sure what you’re suggesting. However, one thing I would like to see in the future is fields that would allow inline editing from the front end of the website. So you’re logged in - you click on a bit of text, edit the content, and it’s all saved inline. This wouldn’t replace the Admin UI, but just be an alternative way of of editing content - some end users would prefer that simplicity. In all reality, whilst I’d definitely like to see this some day, it’s some way off.

Let me know if I’ve missed the gist of what you’re suggesting.

Built in organisational nodes (folders)

I’m not sure about this. PushType doesn’t assume anything about your content - it gives you a blank canvas to setup and structure nodes suited for your site. If you need a Folder node that serves no purpose other than to group bits of content, you should generate such a node.

I’ve never needed a generic Folder node, but I do always create lots of containing nodes like “ArticleList” or “CategoryList”, or “TestimonialList”. Generally these different types of collections require their own templates and have their own behaviours based on the purpose of the content.

Admin UI design

As you may well be aware there is work afoot on a complete redesign of the admin UI. So this is very relevant.

A bit of history first… PushType did used to have a separate PushType::Taxonomy class for creating things like categories. Taxonomies had their own menu in the admin UI and provided a streamlined way of creating nested lists of categories and such.

However, I kept finding that I always wanted my category pages to have content on them - I wanted the taxonomy classes to have fields, with images and text just like nodes. In the end I came to the conclusion that PushType::Taxonomy didn’t really work - it muddied the water. If something is supposed to have content and have it’s own page on the front end then it should be a node. Essentially everything is a node.

So the taxonomy concept was removed, and I envisaged at some point reinstating the UI for managing taxonomies. For example, in your node class you could do something like this:

class Category < PushType::Node
  acts_as_taxonomy
  # ... custom fields
end

This would then bring back the UI for managing the list of taxonomies in a streamlined drag and drop type fashion, but you’d still be able to browse the content tree to edit content of each category. This hasn’t happened yet, but I think something like this will come up again once the new admin UI work gets rolling.

As for the single content tree - well that’s kind of central to the whole premise of PushType so I don’t see that being replaced with smaller mini trees or sets of content. However, I get the argument that it can be a pain to find and navigate to parts of the tree which may be nested several levels deep.

The idea I’ve had to solve this is to introduce some kind of notion of shortcuts or favourites. We could extend the main menu to include our shortcuts, eg:

- Content          -> takes you to the root of the content tree
  | - Blog         -> takes you straight to your blog content
  | - Events       -> etc
  | - Testimonials
- Media
- Users

The exact mechanism for defining these shortcuts is one I’m still mulling over. But just wanted to share my thinking on this. Be keen to hear you thoughts.


(Danny) #3

#Node models with relationships

Please add this to the documentation as soon as possible :stuck_out_tongue:

Reusable Forms

What I’m saying is it would be nice if PT’s forms and widgets for editing, say markdown, or uploading assets could be easily reused in any form.

Built in organisational nodes (folders)

That makes sense put like that :smile:
What I mean is nodes that do not use up other nodes parent_id field. That only exist to organize other nodes in the backend.

#Admin UI Redesign
I love everything you’re suggesting in this section!!! It sounds brilliant and i would love that functionality in the backend. It might be worth creating a dedicated post with those ideas.


(Aaron Russell) #4

I’ve moved the controllers discussion to it’s own thread to avoid this topic becoming a beast. Re your points above:

I think this would be difficult and, to be honest, become even more difficult with the new admin UI, which will be more of a JavaScript SPA. The custom fields will become javascript components and difficult to use outside of the context of the admin UI.

I think you’re suggesting that a Folder class acts as a way or organising content on the backend, without affecting it’s permalink structure on the front end? I don’t like that - I think the structure of the content on the backend should mirror exactly the expected structure of content on the front end. It would be chaotic otherwise.


(Danny) #5

I agree with those counter arguments, no idea how any of those forms work but they’re like magic.

The suggestions you have for the new Admin UI take care of the clutter. :slight_smile: