Q: HowTo Display TableViewBlock on 1 pg of MultiStep/Page form - snippet?

Events happening in the community are now at Drupal community events on www.drupal.org.
johnnelsonritchie's picture

Folks,

I apologize in advance for being a complete newbie but
I have spent days trying to implement a view in a page
of a multi-step form with very limited success.

I am using drupal 6.19 . My goal is to have a database
view/table displayed in the content section on a particular
page of the multi-step form.

The view is of a raw database table (a schema).
The table was created with Table_Wizard and
I defined it as a block.

I can get it to display on all the pages if
I check "Show on only the listed pages" and give the form
name.

If I check "Show if the following PHP code returns TRUE"
and include this snippet:
<?php
($form_state['storage']['step'] == 5 )
>
nothing shows up.

If I try and implement it directly (not as a block)(using
views_embed_view either inline or vial hook_form_alter)
on the particular page, ... it is displayed
but it is placed before the header.

Can anyone coach me on writing the appropriate snippet?
Thanks!!

Also:
In all cases in which the table is displayed, if one
clicks on a column header to resort the table, one
is taken back to the first page of the form.

Any ideas on how this can be prevented.

Thanks much in advance!

Comments

Queestion Restated

johnnelsonritchie's picture

I would like a table_view (created using table wizard) to
be displayed as a block in the content section of a
particular page of a multi-step form, and I would like
the table to display only data for the viewer's uid from
the particular schema being displayed (which includes all
users).

I have two problems. 1.) The first is getting the rendered
table only to display schema entries for the invoking user.
2.) The second is getting the block to be displayed only on
the particular sub-page of the form.

(I should point out here that I have spent days googling
snippets, but with my limited knowledge of drupal jargon)

1).
I am unsure how the page vs block display sub-options
impact my situation. I assume that the block sub-display
is that which is exported to the admin/build/block page.

As this is a block, and on a multi-step form, I am guessing
that I cannot use "url-input" arguments to transfer information
(primarily $user->uid) to the view. (All pages of the multi-
step form display the same URL).

So if I cannot use view page path arguments, thus cannot use
Views_Setting Arguments-Validator-PHP_Code, ... how do I filter
the table to contain only the entries that pertain to the
invoking user? Inexperience led me to try and associate a
'filter' with the uid entry of the schema, seeing if it
"is equal to" $user->uid ... but the latter is unknown,
apparently (and as your video indicated).

2.)
Via admin/blocks/configure... I can choose "Show only on
the listed pages" and give it the form name and the block
will be displayed, in the content section, on all pages
of the multi-step form.

I can also include the views_embed_view command on the
particular page, and the table is then displayed on only
that page, but, it is located before even the header, and
it appears that I have no control over its placement.

Via admin/blocks/configure... I tried "Show only if
the following PHP code returns TRUE" and I entered code
pertaining to values in $form_state ... but apparently
they do not exist in the environment where this PHP code
is accessed. Unfortunately, I do not know how to probe
this environment. Cringingly I must admit that I am also
new to PHP as well as drupal. I was able to reproduce
the "listed pages" control using a snippet I highjacked
from googling :

<?
$show = FALSE;
$path = drupal_get_path_alias($_GET['q']);
if ( $path == "FormName" ) {
$show = TRUE;
}
return $show;
?>

And I use _POST in my form ... but I am unsure if/how I
can reference it here.

I know little about theming at this point and have no idea
whether the manipulation of template files could help me
to do this.

Thanks for any input!

Try this out

druroot's picture

To get the view filtered to items belonging to the current user, you'll want to add an argument:User:Uid. Take a look at the setting to use when no argument is present, there should be a default option here for the currently logged in user. If you have more complex conditions you want to check, you can add some custom argument handling code, but eventually you'll want to return the uid of the current user

global $user;
return $user->uid;

You can always get access to the currently logged in user via the global $user variable.

As far as the multi-step form goes, you're very close. Use views_embed_view(); to inject the view into the form based on the $form_state['storage']['step'] (high five for reading up on the fapi and form_state['storage'] before asking). You can inject a markup form element and adjust the weight to place it anywhere on the form that you want, or you can just use

$form['#prefix'] = views_get_view(...);

to put some content on the top of the form.

johnnelsonritchie's picture

Thanks much for the response. I realize I was
stuck w/the misperception that I needed to use
the block version to control placement ... but
that prevented argument passing. I am still
fuzzy on many issues ... filters vs arguments,
what is available in the environment, where it
is, and how it can be passed. I thought w/the
fixed URL that is displayed for all pages of a
multistep form, that argument passing would not
be possible even for a page_view. I didn't have
luck with the form['#prefix'] approach but the
markup approach worked like a charm. I really
appreciate the input! Believe it or not I
have spent a lot of time slogging through
documentation and Googling ... fortunately or
unfortunately (unusual at any rate) there is a
plethora of stuff out there, but of highly
varying quality/relevance clarity. Easy to spin
ones wheels. Then there are all the different
approaches (I have not implemented CCK (yet?)).
I am a climate research Fortran programmer by
trade, and although I learned basic html back
in the Mosaic days, I have not spent my years
keeping up with the php+ explosion. You saved
me a lot of time and I am grateful! I am under
the gun here. Thanks again!

San Diego DUG

Group categories

Event Classifications

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: