Re: Gallery's K3 class name/dir/file conventions (was "Capitalization")

All looks good for me.  If you miss a few or get a few wrong it's no big
deal, we'll be able to figure them out from context and fix them up.


On Sun, Mar 24, 2013 at 3:34 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:

> Hey Bharat,
>
> Woohoo - I think we've finally arrived on the same page!  Good
> conversation, though... I feel like we both figured out a lot of nuances in
> the process.  Onward!
>
> My roadmap for the near future:
> 1. Finish moving around the remaining files in the gallery module (tonight)
> 2. Fire up a module-wide grep to try and autofix as much as I can to avoid
> changing every class/file name by hand (tomorrow)
> 3. Do the same thing to the user module (next couple days)
> 4. Start getting up to speed on Formo (afterward)
>
> If it helps your workflow, I can invert the order of 2 and 3...
>
> For #2, I could use a little input.  For class names, I'll grep for the
> following patterns (not yet carefully regex-ized, but you get the idea):
> 1. class::
> 2. new Class
>
> Also, I'll look for these, but check them one by one:
> 1. call_user_func, call_user_func_array
> 2. $classvar::
> 3. {$foo . "bar"}::
> 4. new $foo
> 5. new {$foo. "bar"}
> 6. class_exists, method_exists
>
> Additionally, I'll look for other files (media, views), which I think all
> occur within double or single quotes.  I may look for View( just to be sure
> I got all the views.
>
> Any others you can think of that'd be useful to grab?
>
> Take care,
> Shad
>
>
> On 24 March 2013 19:34, Bharat Mediratta <[email protected]> wrote:
>
>>
>> On Sat, Mar 23, 2013 at 3:21 PM, Shad Laws <shad-xpYdmXCiSuZWk0Htik3J/[email protected]> wrote:
>>
>>> If we're sticking with Kohana's functions and not making a
>>> wildcard-savvy loader, then this conversation is kinda moot, but for fun...
>>>
>>> <pseudo-philosophical tangent>
>>> I feel like there are three different cases here:
>>> 1. Not require a rule. (make the wildcard-savvy loader)
>>> 2. Require a rule. (be opinionated and enforce one way to do it)
>>> 3. Require a rule and make you define it. (extra line in module.info)
>>>
>>> While there are certainly arguments why 2 is better than 3, in the
>>> general case, it seems like 1 could often be better than 2, no?
>>> </pseudo-philosophical tangent>
>>>
>>
>> It's not clear to me when that would be the case - so I worry that it's
>> flexibility for flexibility's sake.  I'm ok with that if it doesn't come at
>> a cost, but in this case it makes the explanation harder.  For example,
>> it's easier for me to say "create modules/tag/classes/TagEvent.php and put
>> this in it" vs. saying "create a file in module/tag/classes that ends in
>> Event.php, like TagEvent.php and put this in it".  I'd probably just tell
>> people to use TagEvent in that case.  So then most people would follow this
>> convention - and then what would be the need for a different option?
>>
>> I'm open to this - just want to understand the value proposition.
>>
>>
>>>  I'm a little mixed on this.  Some thoughts:
>>>> - I can't tell if I like the separate subdir or not.  Frankly, that
>>>> implies that there's something to separate from, but many modules can do
>>>> everything they need to do with just and event handler and a block, etc.
>>>>
>>>
>>> Personally, I do.  To me, it has a similar significance to Controller or
>>> Model, in the sense that the names of their functions have special meanings
>>> outside of the class itself.  This is not the case, for example, for the
>>> Tag.php helper, which is why it shouldn't be in any subdir.
>>>
>>
>> I'm definitely coming around to this idea.  I haven't heard a name that I
>> like, yet though.  "Gallery" is used.  "Module" is too close to "Model".
>>  "Hook" is the best I've heard but I'm mildly worried that there'll be
>> cognitive conflict with the fact that some things inside that directory
>> won't be "hooks" per se (tasks, etc).  But the more I think about it the
>> more I like it.
>>
>>
>>> I think by now I'm convinced of all points you just made, with the sole
>>> exception being the separate directory for Gallery-specific stuff.  I think
>>> it gives a meaningful distinction between it and the other stuff.  Also,
>>> it'd give us the added benefit of being able to change our mind at a later
>>> date should someone decide to build an even-more-optimized,
>>> wildcard-capable loader.
>>>
>>
>> Agreed.  Let's go with Hook for now and then if we come up with a better
>> name before launch it should be easy to just fix up everything.  Onwards!
>>
>>
>>> On a semi-related note, how do we feel about underscores in "views"
>>> names?  I like the idea of adding a teeny bit of hierarchy like you did
>>> with the Tag example (certainly no more than 1 level), and that removes a
>>> decent number of them, but not all.  Example: is
>>> /modules/gallery/views/admin/advanced_settings.php fine?  My vote is yes,
>>> personally...
>>>
>>
>> Underscores don't seem to mean anything in view names, eg:
>>
>>   modules/userguide/views/userguide/examples/hello_world_error.php
>>
>> That'd be loaded as "userguide/examples/hello_world_error.php" as far as
>> I can tell.  I can't find good examples of this - but I also don't think
>> that it makes sense for it to be "admin/advanced/settings.php" so I also
>> vote for "admin/advanced_settings.php".  If we find a better model in the
>> future, renaming all this stuff should be easy and backwards compatible.
>>
>> OK!  I think this means it's time to write some code?  I'm going to get
>> going on seeing if I can sort out the IdentityProvider code...
>>
>>
>

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar

__[ g a l l e r y - d e v e l ]_________________________

[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]