Figure out a way to list all views in a directory #8947

Closed
juho-jaakkola opened this Issue Sep 17, 2015 · 11 comments

Comments

Projects
None yet
4 participants
@juho-jaakkola
Member

juho-jaakkola commented Sep 17, 2015

Some plugins have the need to list all views located in a specific view directory. This is not possible anymore in Elgg 2.0 because the $CONFIG->viewpath value has been removed.

It would be nice to figure out either:

  • A new feature that does the job
  • Some kind of a workaround

Example case:

Anypage is using the view location to list all layouts in views/default/page/layouts/, so that user can use the layout of their choice with each anypage object.

Some ideas:

  1. A hook for defining available layouts (initial though is there aren't enough use cases to make it worth adding it)
  2. This works (but is it safe?):
$viewpath = dirname(elgg_get_engine_path()) . "/views/default/";

@juho-jaakkola juho-jaakkola added this to the Elgg 2.0.x milestone Sep 17, 2015

@juho-jaakkola

This comment has been minimized.

Show comment
Hide comment
@juho-jaakkola

juho-jaakkola Sep 17, 2015

Member

Not really a blocker for 2.0, but it would be nice to figure it out before 2.0 stable.

Member

juho-jaakkola commented Sep 17, 2015

Not really a blocker for 2.0, but it would be nice to figure it out before 2.0 stable.

@juho-jaakkola

This comment has been minimized.

Show comment
Hide comment
@juho-jaakkola

juho-jaakkola Sep 17, 2015

Member

Besides core Anypage is also checking for custom layouts provided by plugins.

Member

juho-jaakkola commented Sep 17, 2015

Besides core Anypage is also checking for custom layouts provided by plugins.

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Sep 17, 2015

Member

The views service has $this->locations, mapping [$viewtype][$canonical_view_name] to full file paths.

Member

mrclay commented Sep 17, 2015

The views service has $this->locations, mapping [$viewtype][$canonical_view_name] to full file paths.

@mrclay

This comment has been minimized.

Show comment
Hide comment
Member

mrclay commented Sep 20, 2015

PR #8965

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Sep 20, 2015

Member

@ewinslow are you against exposing this? If so, do you have any other ideas for this use case?

Member

mrclay commented Sep 20, 2015

@ewinslow are you against exposing this? If so, do you have any other ideas for this use case?

@beck24

This comment has been minimized.

Show comment
Hide comment
@beck24

beck24 Sep 26, 2015

Member

This is fine by me - we need something like this to be public API

Member

beck24 commented Sep 26, 2015

This is fine by me - we need something like this to be public API

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Sep 26, 2015

Member

I'd be comfortable with an api that lists views, but not at the directory/filesystem level. You cannot assume anything about the views available just given a directory path.

Member

ewinslow commented Sep 26, 2015

I'd be comfortable with an api that lists views, but not at the directory/filesystem level. You cannot assume anything about the views available just given a directory path.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Sep 26, 2015

Member

I don't see how this use case is addressed by the PR. Views can no longer be guaranteed to reside in a views/default structured directory.

Member

ewinslow commented Sep 26, 2015

I don't see how this use case is addressed by the PR. Views can no longer be guaranteed to reside in a views/default structured directory.

@ewinslow

This comment has been minimized.

Show comment
Hide comment
@ewinslow

ewinslow Sep 26, 2015

Member

We could just as easily have an API that lists all views by name without mapping to a full file path. These views can then be filtered by prefix to determine which page/layouts/* views are available, but then you still need to render them using elgg_view, rather than working directly with the file

Member

ewinslow commented Sep 26, 2015

We could just as easily have an API that lists all views by name without mapping to a full file path. These views can then be filtered by prefix to determine which page/layouts/* views are available, but then you still need to render them using elgg_view, rather than working directly with the file

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Sep 26, 2015

Member

Array of view names per viewtype seems acceptable.

Member

mrclay commented Sep 26, 2015

Array of view names per viewtype seems acceptable.

@mrclay

This comment has been minimized.

Show comment
Hide comment
@mrclay

mrclay Sep 26, 2015

Member

PR #8987 limits the list to view names.

Member

mrclay commented Sep 26, 2015

PR #8987 limits the list to view names.

@mrclay mrclay closed this in 7a699f3 Sep 30, 2015

mrclay added a commit to mrclay/Elgg-leaf that referenced this issue Oct 25, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment