Netzke 1.0 rough roadmap

netzke10roadmap.md

A very rough todo list for the Netzke 1.0 release (WIP)

NOTE: this is not replacement for CHANGELOG (CHANGELOG for Basepack).

Netzke Core

• Currently there's an experimental implementation of the (badly named) clone option in netzkeLoadComponent JS method, which allows loading multiple instances of the same child component, providing different configuration options for each instance. I'd like to consolidate this with the "normal" loading method, and thus get this functionality available by default.
• Concatenating JS mixins should be made less error-prone (dangling commas, etc)
• Routing. In the app I'm currently developing there's a need for routing, and I think I came up with a simple and flexible way to use Ext JS's Controller to do just that (I'm able to use nested routes like "#clients/2/orders/1/items").
• Currently all the component DSL blocks get evaluated at the moment the container component gets instantiated, which in most cases creates unnecessary overhead in memory and performance. I'd like to get rid of that.
• Rethink component folder structure (probably put components in dedicated folders). Get rid of the need to call c.mixin and c.require in the js_configure DSL method; just pick the files if they are there, as it's needed in 99% of cases anyway.
• Find syntax for passing function name in Ruby, that will be called at the client in the component's scope.
• Make it possible to use CoffeeScript for component's client-side code. UPDATE: probably won't happen, given ES6 is coming.
• Make font awesome icons available to the developer (instead of old-fashioned famfamfam) - based on http://extjs.eu/using-font-icons-in-ext-fontawesome/ UPDATE: won't happen; it is easy enough to use glyphs by configuring actions.
• Make possible define components and actions with the same name (currently it'll have a clash).
• Currently, in order to avoid naming clashes with Ext and developer's custom methods/properties, Netzke names them with the netzke* prefix, e.g. netzkeLoadComponent. I'd like to cut this prefix down to "nz".
• Replace netzkeFeedback with nzNotify that'll accept different notification styles (alert, info, etc).
• Last but, actually, the toughest: find a way to generate documentation on component's client-side methods.

Netzke Basepack

• Ext JS provides the awesome buffered store, which enables infinite grid scrolling without degraded performance: http://dev.sencha.com/ext/5.1.0/examples/grid/buffered-store.html - I'd like Basepack::Grid to support that out of the box.
• Implement DnD support for Nodes in Tree
• Implement DnD support for records in Grid
• Reduce duplications in generated code for action handlers (e.g. in actioncolumn)
• Rename Grid#strong_default_attr (can't remember why I named it so) to strong_attrs.
• Get rid of the "enable_*" prefix in Grid options like "enable_pagination".
• default_fields_for_form => form_fields

Generic

• Clear Github issues.
• Sort out licensing with Sencha (probably need to release under the dual GPLv3/? license as well)
• Write a guest post for their blog on Netzke for some exposure.

Hello Max,

Curious to know the issues PennyMac is having (or not having) about component unloading. As it stands it is not implemented yet and likely to have issues when component_session is used. We have a some simple home grown solution for this but I am curious to hear the issues in the real world

ExtJS 6 would be great to have

Good point, about component session, @Mahaswami. I don't know how PennyMac handles it (maybe storing the session in the DB), but for 1.0 I will recommend against using component_session at all, but rather keep the state on the client side. I'll cover this topic in one of the upcoming blog posts, as soon as I've rewritten the component loading part.

As for Ext JS 6, I won't have resources to address it any time soon, at least not before 1.0.

Component session: Our code is heavily reliant on component session right now also the pain is it had to be done in a clugy way. Looking forward to read your blog to see what kind of migration path that is going to be.

EXTJS 6: We would like to contribute towards to EXTJS 6 support if possible if we get a rough sense of the effort involved. At least would like the existing components to work properly in 6.

Could you share

1. How big a deal was this to transition from 4.x -> 5.0 -> 5.1?
2. What places to watch out for?
3. Has ExtJS been a smooth backward compatible on newer releases?

Thanks.

@Mahaswami, concerning the heavy usage of Rails session, please, check out http://blog.netzke.org/2016/01/02/no-more-session-abuse/ - to put things short, the temporary state is now being stored on the client side instead of the session.
As for Ext JS 6 upgrade, it looks like PennyMac wouldn't mind sponsoring it. I do not expect much work upgrading, it was a rather smooth ride since Ext JS 3. So, I could be getting to this soon.