PushType Roadmap

(Kevin Young) #1

I’ve been using PushType for a while now and think it’s a flexible solution for designing complex CMS-backed web apps. However, I’ve noticed a few friction points while developing an app with PushType. I’m interested in some new features. For example:

  1. CMS Search

  2. Additional field options such as:
    a) hidden fields
    b) “filterable” fields (fields that would be filterable in the CMS Search)
    c) polymorphic relation fields

  3. Creation of a PushType::Record class that is not exposed in the CMS. For example some objects don’t need to be exposed in the CMS because they don’t required editing. Instead they are programmatically generated.

Is there a current PushType roadmap? I would like to work on some of these or on any others that may be of priority. However, I noticed that development is pretty slow these days. Do you think the project needs another maintainer? I’d love to see PushType move ahead more quickly.

(Aaron Russell) #2

Thanks for the positive feedback, and yeah, development has been slow for a while. Sorry about that.

About a year ago my small little business went from being a two person business to one person… coupled with me having some time away travelling has resulted in non-paying work like PushType dropping down the priority ladder a few levels.

We’ve got several active clients depending on PushType so it’s definitely not abandoned, but over the last year+ I’ve just had to limit my work on PushType to just keeping it updated with new Rails releases.

There is an old roadmap but it’s neglected and would benefit from serious review. Back then, you can see my main priority was redesigning and rebuilding the admin UI as a SPA javascript app, which I made a rough start on but never really got the ball rolling with enough momentum. I still consider this a big priority and something I want to work on.

In response to your suggestions:


YES! That is on the roadmap above, and honestly the only reason it hasn’t been worked on yet is because I haven’t fully wrapped my head around how you correctly index a Postgres JSONB field to ensure a flexible and performant search feature, and how we’d expose database indexing to site developers so they can easily enable search on their content, without having to know their B-trees from their GiSTs.

This is an important feature and honestly I felt like I needed some help on it, so if this is something you wanted to contribute I’d be more than happy for you to work on it.

Hidden fields

I currently implement hidden fields by manually adding store accessors to the internal json field, eg:

store_accessor :field_store, :my_hidden_field

The above is pretty easy, but I agree there would be some value to create a dedicated field type so developers can use the syntax they expect.

field :my_hidden_field, :hidden 

Polymorphic relation fields

Sounds fun :stuck_out_tongue_winking_eye:

Can definitely see the use case though, so would be happy to see this.

PushType::Record class

PushType already has a concept of unexposed nodes, which hides the content from the front end, but the nodes can still be managed in the CMS. But I think you mean records that would even be hidden from the CMS?

One of the principles I’ve tried to stick to is that PushType should be your CMS and then get out of your way. We shouldn’t recreate stuff Rails already excels at for instance. In this case I think using a standard model is the way to go. I also quite like the notion that PushType could be a way for new developers to build simple sites in Rails with minimal effort, and then introduce them to the framework underneath. Seems a better way than some CMS’s that end up trying to be the framework.

(Kevin Young) #3

Cool. No worries, we all get busy! I think I’ll try and give CMS search a shot sometime soon. I’ll write up some initial requirements/description to have it documented.

I implemented a hidden field option on my PT instance, so I’ll probably extract that and create a Pull Request, if you don’t mind reviewing it.

Re: polymorphic relation fields, here is an example use case: You have several different subscription types (say ProSubscription, StandardSubscription, etc), each with differing fields. You need to associate a user to a subscription. So you have a field :subscription_id, :relation, to: <?>. You might be able to use a module, for e.g. Subscribable, that is included on the different subscription models, as the value passed to the to: option. Then in relation_field.rb detect if it’s a module and which classes it is included in and go from there. I don’t think it’s as high priority as search, but still interesting.

With PushType::Record, yes I mean hidden from the CMS. Sometimes you have a record/object that relates to other Nodes but there isn’t really a use case for an editor to go in and edit it and you don’t really want it taking up space in the UI.

Agreed on your last paragraph.