Just a little fix for a tree_panel. It just work, but is still bad-documented and not-tested

[phgrey]

No description provided.

[mxgrn]

Thanks! I'm merging this in without checking it out myself - afaik, it's been broken for a while.

[phgrey]

Hi!
First - thanks a lot for the netzke. It's realy good. And it saves me
a lot of time.

Another thank for merging this small fix.

I'd like to ask - i've written TreeGridPanel as an extension of
Basepack::Grid.
It has < 100 lines of code and heavy depends on parent (it even uses
it's mixin grid.js)
I'd like to publish it as soon as I'll write tests for this component.
And that's what I'd like to ask You - may I make another pull request
on a netzke-basepack with that component or I should create separate
gem?

Thanks and best regards.
Sergey.

2013/4/22 Max Gorin notifications@github.com

Thanks! I'm merging this in without checking it out myself - afaik, it's
been broken for a while.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/9#issuecomment-16792249
.

[mxgrn]

Sergey,

It'd be simply awesome if you released it as your own gem (having Basepack as dependency). You're free to name it the way you want, but maybe some "brand"-prefix would be handy (something like phgrey-netzke-treepanel) - because @scho, for example, is working on his own version of TreeGrid. Make sure you document it well enough so other people can start using it right away. I'll be happy to list it somewhere on the netzke.org. Really looking forward to what you come up with!

Btw, what are you planning to use for testing? Have you checked out my approach with Mocha + expect.js + RSpec in Netzke Core? Hope it can help.

[mxgrn]

Btw, I totally dig reusing the Basepack code as much as possible. But, please be aware, that the risk here is that your component will be very much dependent on the internals of Basepack::Grid… I hope, with the time we'll work out some way to handle this. If you see where Basepack::Grid code can be refactored to serve you better - I'll be glad to discuss.

Thanks for you work, too!

[phgrey]

Yeah, I'm already trying to use rspec + mocha.js for testing.
Yeah, I think You're right about separate gem. I'm still thinking about
cofee.js runtime dependency.
In the project I'll use several more components (Ext.view etc), will try to
collect them in one gem or several gems If I'll have enough time.

About heavy-dependence - for now I do think to add checking on method
existing in my tests so I'll be able to quick react on changes in
Netzke::Core an Basepack::Grid.

Well, Max, thanks a lot for Your advise and answers. Will contact later
when I'll be ready.
And thanks again for the Netzke!

2013/4/24 Max Gorin notifications@github.com

Btw, I totally dig reusing the Basepack code as much as possible. But,
please be aware, that the risk here is that your component will be very
much dependent on the internals of Basepack::Grid… I hope, with the time
we'll work out some way to handle this. If you see where Basepack::Grid
code can be refactored to serve you better - I'll be glad to discuss.

Thanks for you work, too!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/9#issuecomment-16924164
.

[mxgrn]

About heavy-dependence - for now I do think to add checking on method existing in my tests so I'll be able to quick react on changes in Netzke::Core an Basepack::Grid

I'd say a good (integration) test coverage would be enough.

Especially if you decide to come up with multiple gems (each per (complex) component), we maybe should think about extracting a little Netzke testing micro-framework that can be included into any new netzke gem without writing any code. I already see duplications between Core and Basepack… Will think about it!