Utilize ctools plugins for key methods [#573728]

Well, currently the different methods for keys are hard-coded. The initial thought was to make this hookable, meaning other modules could provide methods for keys.

Now, this is still true, but we should be utilizing CTools plugins for this. (Changing title)

Log in or register to post comments

Comment #7

Alan D. CreditAttribution: Alan D. commented 16 June 2011 at 13:45

For the 40% of sites that do not have views, please avoid having a huge dependency module to save 100 lines of code! cTools is nearly 2MB :(

Log in or register to post comments

Comment #8

zzolo CreditAttribution: zzolo commented 17 June 2011 at 06:43

Hi @Alan. Yes, CTools is big, but the core module, the only one we need, is well designed and minimal, and offers a lot more good functionality that we could write in 100 lines. Also, there is a good chance that the plugin architecture would go into core in D8, or possibly an a path to it. And its an architecture that is widely used, therefore supporting existing knowledge of developers. And finally, I have only created one significant site that did not use Views, so I am not sure where you are getting your 40% from.

Overall, I am not convinced.

Log in or register to post comments

Comment #9

Alan D. CreditAttribution: Alan D. commented 17 June 2011 at 07:56

Weekly Drupal core usage by API version
Week 5.x 6.x 7.x 8.x Total
June 5th 10,016 338,317 35,935 44 384,312

Weekly Views usage by API version
Week 5.x 6.x 7.x Total
June 5th 7,448 253,260 19,364 280,072

OK, 40% was off the top of my head, the official stats, about 25% do not use views.

For personal sites or advanced api sites I do not use any of the point and click modules (views / panels / etc) as they either slow things down too much and are limited in the required functionality. The current site that I'm working on uses only 2 contrib modules, 1 custom module and 2 development ones. Even without caching, it is super fast for a Drupal 7 site.

It will be sad to install 2MB of code just to do something that would require under 100 lines of code if one used manual PHP encryption. Anyway, just my 2 cents.

Log in or register to post comments

Comment #10

theunraveler CreditAttribution: theunraveler commented 17 June 2011 at 14:47

I am also unconvinced.

Is it the disk space you're worried about? You keep mentioning the "2MB of code", but we do not need to actually run all 2MB of that code in order to implement plugin functionality. As @zzolo said, the core functionality is actually quite small and well-written. So, while it may add some bloat in terms of disk space, it shouldn't slow your site down at all, really.

Generally, I am also in favor of using standards rather than homebrewing things. If everyone homebrews their own implementations for common tasks (a problem with Drupal that is being addressed in the WISCC initiative), you ultimately end up with much more than 2MB of bloat.

Log in or register to post comments

Comment #11

Alan D. CreditAttribution: Alan D. commented 17 June 2011 at 15:12

I didn't want to hijack the issue, I was just adding my 2 cents.

For developers:
Pros - less code to write / maintain
Cons - none

For users:
Pros - (hopefully) a better module
Cons - either nothing (for most)
OR
another module to install
a larger footprint
more updates required
slightly higher overhead, even if it is only a few ms. [But it is strange how these quickly add up to seconds - install 50 small modules into the average drupal site...]

Anyway, at least you are picking up on a better api as a base module, unlike some other modules. Right, I say adios and stop polluting this thread with noise and allow everyone to get onto some paid work.