@Jhon<br>
<br>
1) Why is it ok to end up with a directories for Controllers, Views and Helpers?<br>
<br>
I say it's ok only because the framework sets that as a convention. If you use those conventional directories in different contexts namespacing and gems are necessary. <br>
<br>
2) Sometimes you are creating classes that fulfil specific roles within the framework; e.g, Presenters. How do identify their function when they aren’t grouped in a directory?<br>
<br>Sometime the classname has that suffix ie. ValidReservationPresenter. <div><br></div><div><br></div><div><br></div><div>@mark</div><div><br></div><div>As application complexity grow moving away from AR conventions (ie. validation and relationships) is a must. I like your db namespace approach, sometime I think of AR as a repository so you could use that keyword.</div><div><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)">> gradually introduce this kind of structure as appropriate.</span></font><br></div><div><font size="2"><span style="background-color:rgba(255,255,255,0)"><br></span></font></div><div>Agreed that on a small app this approach can be unnecessary, but I've rarely seen an app staying small so knowing when to introduce is very important. I hope my article gave that insight. </div><div><br></div><div>
<br>
On Wed, Sep 9, 2015 at 5:20 AM, Mark Burns <<a href="javascript:;" onclick="_e(event, 'cvml', 'markthedeveloper@gmail.com')">markthedeveloper@gmail.com</a>> wrote:<br>
> This is an approach that has worked well for me on a couple of projects.<br>
> I think I gave up on fighting rails about where to put the views and the<br>
> controllers, and had a mix of approaches. I.e. only moving towards this<br>
> approach for the obvious cases.<br>
> Where there is a clear grouping of a large enough bunch of related items<br>
> e.g. DictionaryEntry, DictionaryEntryPresenter, DictionaryEntryCreation,<br>
> etc. then it makes it easier to navigate and fits in well with the concept<br>
> of connaissance.<br>
><br>
> It does lend well to namespacing, which then leads nicely into separating<br>
> into engines. And in one case, for an unused area of functionality it was a<br>
> surprising case of<br>
> rm -rf dictionary_entry specs/dictionary_entry<br>
><br>
> Run the specs and everything still works. Feature removed! (Then just<br>
> quietly remove the views and controllers/routes afterwards).<br>
><br>
> Didn't have time to look into getting that aspect smoothly done. But I would<br>
> probably better spend that time looking at trailblazer, which seems to have<br>
> a lot of great concepts in it.<br>
><br>
> Along these lines, I quite enjoy the concept of keeping the spec close to<br>
> the implementation as golang does. I've only gone as far as domain concept<br>
> based folders in the spec folder as mentioned. I'd be interested to hear if<br>
> anyone has had success with a directory listing that looks like this:<br>
><br>
> dictionary_entry.rb<br>
> dictionary_entry_spec.rb<br>
><br>
><br>
> The only fiddly issue apart from the views/controllers folders was with AR<br>
> and namespacing based on the domain concept. Which would traditionally be<br>
> the ActiveRecord model name.<br>
> E.g. rather than pollute a DictionaryEntry AR model with tons of classes, I<br>
> ended up namespacing all my AR models as Db::DictionaryEntry etc.<br>
> Which when you have lots of objects in an app serves a dual purpose of<br>
> hinting which one is the thing that writes to the db. Probably a<br>
> double-edged sword, hungarian notation anybody?<br>
><br>
> But equally, on a small app, with a few presenters, a few controllers and<br>
> non-obvious groupings then it is overkill. It doesn't really cost much more<br>
> to gradually introduce this kind of structure as appropriate.<br>
><br>
> On Wed, Sep 9, 2015 at 5:59 PM <<a href="javascript:;" onclick="_e(event, 'cvml', 'jc@panagile.com')">jc@panagile.com</a>> wrote:<br>
>><br>
>> Hi Enrico,<br>
>><br>
>> Thanks for sharing this. It’s an approach that I agree with in general -<br>
>> I’d much rather classes were grouped by domain than by pattern. I have got a<br>
>> couple of questions though:<br>
>><br>
>> 1) Why is it ok to end up with a directories for Controllers, Views and<br>
>> Helpers?<br>
>><br>
>> 2) Sometimes you are creating classes that fulfil specific roles within<br>
>> the framework; e.g, Presenters. How do identify their function when they<br>
>> aren’t grouped in a directory?<br>
>><br>
>> (Or maybe my assumtion at the start of the second question is wrong, in<br>
>> which case I’d like to hear why.)<br>
>><br>
>> Thanks,<br>
>> John<br>
>><br>
>><br>
>><br>
>> On Tue, Sep 8, 2015 at 5:43 PM, Enrico Teotti <<a href="javascript:;" onclick="_e(event, 'cvml', 'enrico.teotti@gmail.com')">enrico.teotti@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> I wrote a blog post on (Rails) application directories named as<br>
>>> architectural patterns and suggesting a more intention revealing<br>
>>> alternative:<br>
>>><br>
>>><br>
>>> <a href="http://teotti.com/application-directories-named-as-architectural-patterns-antipattern/" target="_blank">http://teotti.com/application-directories-named-as-architectural-patterns-antipattern/</a><br>
>>><br>
>>> Ciao,<br>
>>><br>
>>> Enrico<br>
>>><br>
>>> --<br>
>>> [skype] enrico.teotti<br>
>>> [web] <a href="http://teotti.com" target="_blank">http://teotti.com</a><br>
>>> [twitter] agenteo<br>
>>> _______________________________________________<br>
>>> Chat mailing list<br>
>>> <a href="javascript:;" onclick="_e(event, 'cvml', 'Chat@lists.lrug.org')">Chat@lists.lrug.org</a><br>
>>> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
>>> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
>>> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Chat mailing list<br>
>> <a href="javascript:;" onclick="_e(event, 'cvml', 'Chat@lists.lrug.org')">Chat@lists.lrug.org</a><br>
>> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
>> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
>> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
><br>
> _______________________________________________<br>
> Chat mailing list<br>
> <a href="javascript:;" onclick="_e(event, 'cvml', 'Chat@lists.lrug.org')">Chat@lists.lrug.org</a><br>
> Archives: <a href="http://lists.lrug.org/pipermail/chat-lrug.org" target="_blank">http://lists.lrug.org/pipermail/chat-lrug.org</a><br>
> Manage your subscription: <a href="http://lists.lrug.org/options.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/options.cgi/chat-lrug.org</a><br>
> List info: <a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
><br>
<br>
<br>
<br>
--<br>
[skype] enrico.teotti<br>
[web] <a href="http://teotti.com" target="_blank">http://teotti.com</a><br>
[twitter] agenteo<br>
</div><br><br>-- <br>[skype] enrico.teotti<br>[web] <a href="http://teotti.com" target="_blank">http://teotti.com</a><br>[twitter] agenteo<br>