Forum .LRN Q&A: Sanity check: portal_datasource.AddSelfToPage is not polymorphic?

I noticed that the various tcl procs implementing the portal_datasource.AddSelfToPage operation have differing signatures. For example,
  • faq_portlet::add_self_to_page has three required arguments,
  • dotlrn_portlet::add_self_to_page has two required arguments,
  • forums_portlet::add_self_to_page has four required arguments.
This means you can never write code that looks like this...
acs_sc_call portal_datasource AddSelfToPage [list $page_id] $impl_name
Even if we add an "args" argument here, we can't stuff it correctly without knowledge of the implementation.

New-portal authors, is this correct? I call this a "sanity check" because, if correct, this would seem to defeat the purpose of service contracts.

Here is a list of all ad_procs matching "*::add_self_to_page" along with their required switches.

fs_portlet::add_self_to_page
-portal_id
-package_id
-folder_id
-param_action
dotlrn_main_portlet::add_self_to_page
-portal_id
dotlrn_homework_portlet::add_self_to_page
-portal_id
-package_id
-folder_id
-param_action
forums_portlet::add_self_to_page
-portal_id
-package_id
-display_group_name_p
-param_action
calendar_full_portlet::add_self_to_page
-portal_id
-calendar_id
static_admin_portlet::add_self_to_page
-portal_id
-package_id
dotlrn_members_staff_portlet::add_self_to_page
-portal_id
-community_id
faq_admin_portlet::add_self_to_page
-portal_id
-package_id
bm_portlet::add_self_to_page
-portal_id
-package_id
dotlrn_homework_admin_portlet::add_self_to_page
-portal_id
-package_id
-folder_id
-param_action
research_portlet::add_self_to_page
-portal_id
calendar_list_portlet::add_self_to_page
-portal_id
-calendar_id
survey_admin_portlet::add_self_to_page
-portal_id
-package_id
calendar_admin_portlet::add_self_to_page
-portal_id
-calendar_id
dotlrn_members_portlet::add_self_to_page
-portal_id
-community_id
news_portlet::add_self_to_page
-portal_id
-package_id
-param_action
research_admin_portlet::add_self_to_page
-portal_id
calendar_portlet::add_self_to_page
-portal_id
-calendar_id
forums_admin_portlet::add_self_to_page
-portal_id
-package_id
syllabus_portlet::add_self_to_page
-portal_id
-package_id
syllabus_admin_portlet::add_self_to_page
-portal_id
static_portlet::add_self_to_page
-portal_id
-package_id
dotlrn_portlet::add_self_to_page
-portal_id
-community_id
faq_portlet::add_self_to_page
-portal_id
-package_id
-param_action
dotlrn_forums_admin_portlet::add_self_to_page
-portal_id
-package_id
dotlrn_admin_portlet::add_self_to_page
-portal_id
-community_id
survey_portlet::add_self_to_page
-portal_id
-package_id
-display_group_name_p
-param_action
fs_contents_portlet::add_self_to_page
-portal_id
-pretty_name
-folder_id
-param_action
news_admin_portlet::add_self_to_page
-portal_id
-package_id

(generated from sloanspace ad_proc metadata)

That is correct, add_self_to_page is not directly generically callable.

The non-generic add_self_to_page procs are wrapped, in dotlrn, by
add_portlet_helper procs which are called generically when templates
are created. then they are called again in the add_applet_to_community
and add_user_to_community procs which fill in the parameters with
their correct values.

i can only think of one place where you would want to call
add_self_to_page procs generically (where the elements are there but
filled with non-working values): when creating templates. there could
be others, but i can't think of any right now. so, while this should
be cleaned up in a future release, i don't see it as a major concern
for the present.

the datasource contract is still useful even if add_self_to_page procs
cannot be called generically. other procs in the contract are called
generically by the code e.g. "Show" and "GetPrettyName".