lucidworks / lucidworks-view

Create custom user experiences for your Fusion-powered apps.
https://lucidworks.com/view
Apache License 2.0
37 stars 23 forks source link

Redo doc templates for easy templating #37

Closed arijitdasgupta closed 4 years ago

arijitdasgupta commented 8 years ago

Changes to document based templating system in Lucidworks View.

Previously we used switch on _lw_data_source_type_s field to select which template to show, with each document type being a separate directive. In most case that resulted in repeat in boilerplate code, change in lot of place to copy one template and only one way to select templates.

We changed that by splitting the templating into three different sections, with one directive to manage it all.

The sections are

  1. The HTML template itself
  2. The controllers
  3. The stylesheets

So now, each of these separate components of the templates can be changed/added/removed without messing with others, and each component needs registration on a file.

  1. In order to add a new template, one can just drop in a new HTML file in document/<document_type>/document_type.html directory and add the filename to the list of document based predicate -> template mapping in document/documentConfig.js as described in the file's comments. The template will have vm binding available to it, which is the context of that document, containing a doc object. Also vm will have SendSignal from it's parent that the template will have access to.
  2. To use a custom controller to change parts of the doc or adding some behaviour, one can add their own controller in document/<document_type>/documentTypeController.js. To hook to it's parent's binding, it can use $scope.$parent.vm. Also the new controller needs registration at document/controllers.js. A boilerplate controller would be document/document_file/documentFile.js. To actually use the controller in the template, one can use ng-controller=NewController.
  3. To add styles, one can drop a new _*.scss stylesheet in document/<document_type>/document_type.scss. It also needs to be imported in document/_document.scss. It's recommended that the custom styles-templates use a class handle.

This PR is ready for review.

JoshEllinger commented 8 years ago

We are now asking people to edit files in 3 places now. Would it be simpler for the end user if we kept the structure of folders per type, while having the flexibility of just having an HTML file if that is all you need? This change would make code sharing easier, you can have a document self contained in a node module etc.

arijitdasgupta commented 8 years ago

Right yeah. Yeah we can keep the structure. I thought in terms of adding as you go model, you can keep adding new templates without creating folders etc., less time to get one template up and running.

I think with some gulp magic, we can keep have the structure like before no problem.

arijitdasgupta commented 8 years ago

Added little more templateCache magic

arijitdasgupta commented 8 years ago

@JoshEllinger changed all the files to snake case for easy development..

arijitdasgupta commented 8 years ago

Updated to develop

erikhatcher commented 8 years ago

I'm curious, say, client/assets/components/jira_issue/jira_issue.js - why is that file even needed? What does it provide that shouldn't just be "built-in" (or like signals, wired in with snowplow-esque indirection)?

It sounds like the crux of this work in this PR is to not require the .js file for a document template.

I'm a huge cheerleader of keeping it DRY - https://en.wikipedia.org/wiki/Don%27t_repeat_yourself - not WET - so I'm excited to see the steps made here already.

JoshEllinger commented 8 years ago

Formatting changes so the date is human readable. There may be a better looking solution for this, but current structure gives you complete control of how things can be formatted, beyond date formatting.

On Tuesday, May 31, 2016, Erik Hatcher notifications@github.com wrote:

I'm curious, say, client/assets/components/jira_issue/jira_issue.js - why is that file even needed? What does it provide that shouldn't just be "built-in" (or like signals, wired in with snowplow-esque indirection)?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lucidworks/lucidworks-view/pull/37#issuecomment-222710011, or mute the thread https://github.com/notifications/unsubscribe/AAGt65xIXdhk2TARC54GwtLoH0hXWCroks5qHEitgaJpZM4Imtwl .

erikhatcher commented 8 years ago

forgive my ignorance - I'm looking at https://github.com/lucidworks/lucidworks-view/blob/9e8fdaac428e0cdff6fa4404d6145a46a8f6ea21/client/assets/components/jira_issue/jira_issue.js - where's date formatting in there? Am I looking at an outdated file?

JoshEllinger commented 8 years ago

This file has updated jira changes https://github.com/lucidworks/lucidworks-view/blob/9e8fdaac428e0cdff6fa4404d6145a46a8f6ea21/client/assets/components/document/document_jira/document_jira.js

On Tuesday, May 31, 2016, Erik Hatcher notifications@github.com wrote:

forgive my ignorance - I'm looking at https://github.com/lucidworks/lucidworks-view/blob/9e8fdaac428e0cdff6fa4404d6145a46a8f6ea21/client/assets/components/jira_issue/jira_issue.js

  • where's date formatting in there? Am I looking at an outdated file?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/lucidworks/lucidworks-view/pull/37#issuecomment-222715811, or mute the thread https://github.com/notifications/unsubscribe/AAGt69PXDLzpEANyxD2ev2g3QhYYZmagks5qHEzfgaJpZM4Imtwl .

erikhatcher commented 8 years ago

Ah so, sorry for the confusion @JoshEllinger - that one definitely looks better!

arijitdasgupta commented 8 years ago

@erikhatcher

In that instance that piece of JS serves no purpose (except the signal part) but to define the map that is <jira-issue> to something like <p>....</p>. Ideally we can get away with removing the use of a directive there altogether and using a different replacement mechanism that we have done with document in this PR, but that will make the codebase slightly more complicated.

So most of the components except the document rendition is still following the standard directive.js, directive.html pattern, and also keeping these boilerplate patterns might solve a very niche usecase where someone wants a little hack on the display of some data field. Which is also true for the case of documents but since we want document renderers much easier to create, we sort of changed the <directive> to HTML glue to be slightly more smart.

Does that make sense?

arielisaacs commented 8 years ago

This is not urgent, and can be done when you are on View @JoshLipps

arijitdasgupta commented 4 years ago

Closing due to inactivity.