Closed (fixed)
Project:
FeedAPI
Version:
6.x-1.x-dev
Component:
Code feedapi (core module)
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
16 Feb 2009 at 16:23 UTC
Updated:
18 Aug 2009 at 10:04 UTC
Jump to comment: Most recent file
Comments
Comment #1
aron novakWell, while I started to implement this, I realized that this step would be equal with breaking 3rd party feedapi modules :)
I'd vote only for feedapi.admin.inc and feedapi.opml.inc .
Logically feedapi_parse should live under the feedapi.inc. But in Drupal 6 we do not have that elegant drupal_function_exists() function, this means that 3rd party modules should be aware of including the right files just in time.
In Drupal core, the explosion of aggregator into tons of .inc files is only started from Drupal 7, there is a good reason for that :)
Comment #2
aron novakThe first part (opml / admin.inc) is committed.
For the others, here is a patch.
The new feedapi.inc is almost 400 lines long :)
Comment #3
alex_b commentedLooking good, I like how this module starts to shrink.
1) Shouldn't _feedapi_sanitize_processors() go to feedapi.inc ?
2) _feedapi_get_stat() should not be in feedapi.inc but in feedapi.admin.inc, right?
3) Should we move the internals of feedapi_form_alter() into _feedapi_content_type_form_alter() in feedapi.admin.inc and a _feedapi_node_form_alter() in feedapi.inc ? feedapi_content_type_validate() and feedapi_content_type_submit() could move with it.
Comment #4
avpadernoTo move the internals of
feedapi_form_alter()infeedapi.admin.incwould not help much.It makes sense to pass the code to an external file only when Drupal automatically includes that file; if the module must manually include the file, then it should be better to keep the code in the main file (generally speaking).
Comment #5
aron novakdone already