-
Notifications
You must be signed in to change notification settings - Fork 459
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[enhancement] Support for .dust and .properties files under public/components #119
Comments
I'm unable to reproduce this. I've placed three dust templates along the tree, and they rendered fine:
from {>"layouts/master" /}
{<body}
<h1>{@pre type="content" key="greeting"/}</h1>
{>"small" /}
{>"../smaller" /}
{>"../../smallest" /}
{/body}
Am I missing anything? Feel free to reopen as needed. |
Thanks Lenny, I confirmed that a simpler example does work. I must have had some other code issue before. 😌 I'd like my the public/components/small/templates/small.dust:
I will explore what happens when I try this to figure out where to store my |
@lmarkus , is it possible to compile these templates that are outside /public/templates using grunt build? Or is it necessary to add these paths to Gruntfile.js? |
In development mode, kraken will compile them on the fly. |
@lmarkus 👍 |
@tsullivan Are you ok with using relative paths though, i thought you wanted something that worked seamlessly with bower components ?
etc. |
@pvenkatakrishnan I'd prefer to use relative paths for partials outside of public/templates, that only has impact to those cases. Pointing views config to public seems would impact how every partial is included, not just component partials, and that's not ideal. The choice to use components with Dust partials shouldn't affect how you use all partials in your project. |
Changed the issue headline to be more generic for the need of having Dust files and Properties files organized under public/components, which is the location that PayPal's bower components will be installed into for PayPal apps. The PayPal bower components will provide a few different kinds of files:
As an example, as a PayPal UI Engineer, if I want to use a component named "credit-card-entry" then I would do
Where does Kraken come into this?
This enhancement would introduce a MAJOR benefit for PayPal UI Engineers not "reinventing the wheel" for front-end experiences. |
I'm just wading into this, but would it be possible to resolve this issue with symbolic links using relative paths under the existing contentPath and templatePath directories? |
Requiring symlinks is a no-no for a long term solution 😄 What about creating something like a Additionally, as @tsullivan / @pvenkatakrishnan mentioned, we'll need to adjust a few settings to ensure that content and builds work. |
Tagging for 1.0 milestone. |
@jeffharrell Can you elaborate on why symlinking is a no-no? We could dynamically create sym links at some point in the application lifecycle based on config and environment. Nevermind, I already found a pretty big flaw with that solution. |
OK. With some guidance from @jeffharrell I looked at some grunt/bower tasks which copy component files around using various configuration approaches. The one that is closest to fitting the need here is grunt-bower-task. For this solution I had to propose a minor change: yatskevich/grunt-bower-task#114 I used my fork of the task, and created a sample kraken-js 1.0 app: https://github.com/grawk/bowerz Please check it out, comment there or here. |
Because I'm still not convinced that copying is the way to go, I worked up another branch of bowerz which uses symlinks (via my fork of the grunt-contrib-symlink repo). Please see the README for instructions on usage: |
I like the idea @jeffharrell mentioned regarding |
Attempting to achieve multiple dust roots (as per @jeffharrell 's suggestion) while appealing from an end-user perspective, is complex from an implementation perspective. Express wants a single template root. Trying to add an additional root for this use case is a lot more complex than just symlinking or copying files to the current template root. Perhaps someone from the community can attempt to follow up on the {@component} concept. In the meantime, I've provided two feasible workarounds via either grunt-contrib-symlink (recommended due to the better support of this task module) or grunt-bower-task. You can see the bowerz example kraken app for an explanation of both: |
If we want to use Bower components in a Kraken app that contain CSS, JS and Dust files, Bower would not typically install the front-end package files be under
public/templates
. However, it is not currently possible to render templates that are not withinpublic/templates
, and relative path references don't work using the Dust renderer.Example:
public/components/component-name/templates/partial.dust
public/templates/layout/master.dust
Dust partial includes in Kraken are always relative to
public/templates
, but including the partial this way does not work:{>"../components/component-name/templates/partial" /}
The Dust renderer ignores the leading
../
part of the partial's path and gives the error:Error:ENOENT, open '/Users/tsullivan/webapps/app-name/public/templates/components/component-name/templates/partial.dust
The text was updated successfully, but these errors were encountered: