Reorganise where files are saved #65

Closed
wants to merge 1 commit into from

9 participants

@Nerian

Currently the generated files looks like this:

widgets/parent_widget.rb
widgets/parent/parent_view.html.slim

widgets/parent/child_widget.rb
widgets/parent/child/child_view.html.slim

So in the same folder, we find both view pages from the parent widget and widget code from the child widget.

Unrelated information in the same folder == mess.

I propose to change it to:

widgets/parent/parent_widget.rb
widgets/parent/views/parent_view.html.slim

widgets/parent/child/child_widget.rb
widgets/parent/child/views/child_view.html.slim
@Nerian Nerian Generated widgets are saved inside their own folder. Inside a widget'…
…s folder there is a 'views' folder, where its views are located. This makes tree of widgets much more cleaner, since now there is separation between where the code and views are located
fd8a6f5
@docwhat
widgets
├── kaminari
├── panel
│   ├── list
│   │   ├── contents
│   │   │   ├── course
│   │   │   │   └── views
│   │   │   └── views
│   │   ├── header
│   │   │   └── views
│   │   └── views
│   ├── new_course
│   │   └── views
│   └── views
└── users
   └── panel
@docwhat

Sorry, that was an example structure give by Nerian. Each 'sub-widget' gets its own directory, which makes it easy to figure out that 'list' is a sub-widget of 'panel' for example.

@Nerian

This pull request is not complete, it just a discussion starter.

I have changed the generators so that they create the aforementioned structure of folders. There are more things that needs to be changed; for example, apotomo need to be aware of the new location of the views files. I don't know how to change that. Perhaps it need to be done at Cells.

@Nerian

This is how the proposed structure looks like for a simple 2 levels widget:

Alt Text

And a complex one:

@apotonick
Owner

Looks cleaner. This ain't gonna be easy to introduce since it changes the entire assets layout. Maybe we can have a module AlternativeAssets in cells? Why not start a discussion on the mailing list about that, I guess there will be some good opinions there. Can you send a mail to it?

@Nerian

I think it is better if we just support one way to do it. Less complexity in the long term.

But I agree in that it is a major change. Maybe is time for Cells 4.x.x :)

I'll send an email to the list

@jcquarto

where would a "layouts" folder go? as per some of the examples on the apotomo.de site, this was always a question anyway....but with this proposed change, it seem it would be a sibling-folder to Views? or a child? And would it be available to that widget and its descendent, only?

@ragrawal

This is just a half baked suggestion but I am wondering is it possible to have rails like directory structure. Widgets are more like of a controller. So we can have a controller folder inside widgets and a view folder. With view folder there will be different folder for each widget. Generally I hate having very deep file structures and its just make them browsing difficult. Instead we can have some navigation convention to quickly find files. Below is an example of what I am thinking

widget:
controllers
panel_widget.rb
panel_list_widget.rb
....
views
panels
index.html.erb
add.html.erb
remove.js.erb
...
panel_list
update.html.erb
update.js.erb
....

@Nerian

@jcquarto

We can put layouts inside the views/ folder of each widget. No need to create a subfolder. We can use naming convention like *_layout to differentiate it from normal views.

Layouts inside the view folder of a widget will be just available to that widget. We can have widgets/views/ where global layouts can be stored. Those would be accessible from all widgets.

The widgets/views/ folder would store both layouts and views. Anything that we want to make available for all widgets. For example, views for pagination.

@ragrawal

I prefer a self contained widgets structure instead of spreading every widget on widget/controllers/ and widget/views/. It would be easier to navigate.

@Nerian

Also, as per the mailing list discussion, we can create css/ and js/ folders for each widget and have it work with Sprokets.

That would be totally epic.

So:

widgets/list_of_courses/
            list_of_courses_widget.rb
            views/
                display.html.slim
                display_layout.html.slim
            javascript/
                display.js.coffee
            stylesheets/
                display.css.sass

widgets/views/                                # Accessible by all widgets
             widget_layout.html.slim     
             a_partial.html.slim

This looks seriously good :)

@Nerian

@apotonick Thoughts? :)

@wmhobbes

I just started working with apotomo these days but this reorganization proposal, including assets, looks much cleaner than the current state. Unless I'm missing something, of course.
Is this still being worked on?

@blazes816

I'm a user of Cells, but not Apotomo. Is there any reason this type of change is happening in Apotomo instead of Cells? I'd much prefer this layout, including the asset pipeline integration. I'm looking at starting to make Cells do this, but was wondering if there was a reason you are all looking to do this at the Apotomo level.

@Nerian

@blazes816 The only reason is that I used Apotomo and not Cells at the time I made this pull request :)

But I agree with you in that this change should be made at Cell's level and then propagate to Apotomo.

@blazes816

Alright great, thanks. Just making sure I wasn't missing something. I'll start on making it work in Cells.

@apotonick
Owner

Right, this will go to cells. Can anybody explain how we would test the whole assets change?

@apotonick
Owner

Yeah but this is just the generator, we also have to make the view finding work, and everything is running ok in a Rails app with asset pipeline etc. That's what I'm asking for.

@blazes816

I would imagine the same way assets are tested for Rails core. I'll dig around in their tests and see if I can find anything specific.

@blazes816

Here's what I have so far: https://github.com/blazes816/cells/tree/nested_cells

No asset pipeline yet. Just the nested structure.

@blazes816

Note that render :partial isn't working. I'm working on figuring that out since it looks like rails handles that directly.

@kristianmandrup

I have implemented a similar approach in my fork. The specs pass. The widget generators now support generation of coffeescript or javascript assets and stylesheet stubs for each widget. I would like to compare this with @blazes816 solution to see if we can merge the approaches.

@apotonick
Owner

Hey @kristianmandrup I checked your fork and it looks like the alternative view layout is pretty simple to implement. I'd love to do that in cells itself. If we can get your coffeescript/.. generators to work and @blazes816 asset pipeline it would be perfect.

@kristianmandrup

Hi @apotonick. Nice to hear that you liked the general idea of my new view layout structure. I agree that the asset pipeline integration with coffee/javascript, styles etc. could be improved and make a for a nice complete package. I think we need a few good cases/examples in order to sanity test any such solution. I haven't looked into @blazes816 work yet. I will be looking more into it later in the week. Feel free to grab what ever you find useful from my fork. Cheers!

@kuraga

Hello! Why don't you consider more Rails-way: app/widgets, app/widgets_views?

@kristianmandrup

Yes, that was also an option I thought about. The only problem with this design, is that it makes it harder to move around a widget, fx changing the namespace. Then you have to synchronize within two separate folders.

app/widgets/controllers and app/widgets/views might be an idea? why not have helpers, decorators or even commands also? Lot's of options!

@kuraga
@apotonick
Owner

I'd love to have widgets as a self-contained folder to make reusability across projects as simple as possible. Something like

app/widgets/comments
app/widgets/comments/comment_widget.rb
app/widgets/comments/views/..
app/widgets/comments/helpers/..           

Or is that stupid? I guess Kristian proposed that a long time ago and I promised him to write it (also, a long time ago) ;-)

@kuraga

Yes, he did it, and I should recreate this patch (it's our agreement :-)). But I think it should be rewritten for Cells...

@kristianmandrup

Yes, that was the alternative approach - breaking the "rails structure convention", which makes it easy to move everything belonging to one widget in one go, like changing internal namespace structure, without having to synchronize in various disparate places!!!

I also believe it belongs more in cells? perhaps next major version (major breaking changes!)

@apotonick
Owner

It should be in cells, right. We could introduce a switch where you can have the old behavior back. Now we need to discuss the structure thoroughly before we implement it. BTW- I don't see a problem with breaking Rails' convention here as I am not a big fan of the global directories at all!

@kuraga

Some news?

@apotonick
Owner

This is now implemented in Cells: apotonick/cells@25b65d1

@apotonick apotonick closed this Apr 10, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment