Laravel-log-viewer: Request: Split view into layout + content

Created on 14 Sep 2015  ·  9Comments  ·  Source: rap2hpoutre/laravel-log-viewer

After the suggestion here:

https://github.com/rap2hpoutre/laravel-log-viewer/issues/39#issuecomment-139873059

The idea is to have separate views - one for the layout, i.e. the page wrapper, and one for the content - the tables. Anyone wanting to put the content into their own layout templates in their own application, will need to split the view like this as the first step, so it will help a lot to build it like this in the first place.

enhancement

Most helpful comment

perhaps an even better solution:

Rap2hpoutre\LaravelLogViewer\LogViewerController

  • Create protected variables named $viewLogFile(string) and $viewLayoutFile(string) which are used in View::make($viewFile...)

This allows you to simply create your own LogViewerController which extends the Rap2hpoutre one. Then just set the $viewLogFile or $viewLayoutFile to use your own view-container as the parent.

All 9 comments

I agree. What about just adding sections?

Yes, this would be the usual way to provide hierarchical structure to the views.

+1

Any suggestion about what section I should add? I don't need to build my own view so I have no idea where I should add sections. I'm open to PR, if there is none in a few days I will make my own section hoping it's OK.

perhaps an even better solution:

Rap2hpoutre\LaravelLogViewer\LogViewerController

  • Create protected variables named $viewLogFile(string) and $viewLayoutFile(string) which are used in View::make($viewFile...)

This allows you to simply create your own LogViewerController which extends the Rap2hpoutre one. Then just set the $viewLogFile or $viewLayoutFile to use your own view-container as the parent.

Yes! Could you please make a Pull Request for this? Thanks!! (If you don't want just tell me and I can do it myself)

As a general point, hard-coded strings and other values would certainly benefit from being properties of the controller, whether they are changed by overriding the controller or through some kind of setter or injected config. So this is certainly a good idea anyway, allowing the main entry point to the log viewer page to be changed easily.

The main point of this issue though, was to split the single view up into embedded layers, that can be put together in other ways, or have layers overridden without having to override the entire page view. As well as the page wrapper, there is the main log table, and also the side-bar list of log files. All these would ideally be partials (views included in views) IMO.

I should be getting back to my project that uses this later in the Summer, so can create a PR then, if someone else hasn't already done so.

This issue is super old (3 years) and I only maintain this package without adding new features. I close this issue. Feel free to ask for reopen.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

rap2hpoutre picture rap2hpoutre  ·  7Comments

DevynCJohnson picture DevynCJohnson  ·  5Comments

akoepcke picture akoepcke  ·  9Comments

serdarsaygili picture serdarsaygili  ·  11Comments

mhousser picture mhousser  ·  11Comments