In the polymer.json file is there anyway to point to multiple points of entry?
"entrypoint": ["index.html", "index2.html", "index3.html"]
Or would it be best just to include the other indexes in the fragments section?
This would be for a domain and some sub domains.
example.com
app.example.com
shop.example.com
I don't really need this but it would be nice to have one folder for production.
I'm just adding text to satisfy the validation.
Thanks for your time in advance
Remember a polymer "application" is a single application, it's a single page, except it's not really a page at all, it's an application.
Having multiple entrypoints doesn't make sense, because loading that entry point is really just loading an application specified in that file... index.html is a sort of manifest and bootstrap that starts your application.
If you have multiple entry points, these are different applications, which will involve page load. Either build them as three different apps, and share the common code in libraries of your custom elements, etc, or refactor your applications so there is one index.html/app load entrypoint, and load the features that make up index2.html and index3.html as fragments.
Perhaps all your index?.html files are really views, different "screens" in your application, and you should make them all fragments, and in index.html have the shared code load the original index123.html's as views.
Related
Is there a way for an organization that uses a series of Jekyll blogs (ideally running on Github Pages) that are related in that they'd have the same header, style, and footer, but manage separate contents to work together? The blogs are necessarily separate because the idea is that each should be able to stand on its own, but should still work nicely together. Specifically the concern is local development.
To see the specific use case, check out Open Source Design, and how it plays out on the actual website. Right now changing a style for the jobs subdirectory involves copying over the CSS, tweaking it, and moving it back to the the website.
Something I've seen work for rails apps and might be an idea is looking into setting up Anvil to work with Jekyll instances to power all the instances? Is there anything out there that has tried that?
organisation.github.io is the repository that manage organization wide styles in organization.github.io/css/main.css.
Any layout in a repository at github.com/organization/project will use the central css at organization.github.io/css/main.css. Any specific css can be in the repository itself.
This is also true for javascript files with no fear of cors.
The only problem can be for local development and the need to link css with an absolute path to online resources.
Note that Open source design is already doing this, pointing all pages to http://opensourcedesign.net/css/main.css or /css/main.css which is the same file.
I would suggest that what are you trying to do is outside the scope of a static site generator. You need to configure assets based on the environment in which they will be used. You need a build system like grunt, gulp, or even Rake. The build system can pull assets from a single source folder, pre-process them as needed (changing asset URLs as needed), and move them to various output directories for each of your blogs.
Or you could try to put your assets in one repo and make each of your other repos depend on the assets repo as as submodule. Then you can update the assets independently of the contents.
I have a multi-language site organised into directories (e.g., pages_EN, pages_FR, etc.), each directory containing webpages such as index.html, contact.html, and referencing common files in separate directories (e.g., "../images/picture.jpg") and external css and js files. This structure has allowed me to copy the code wholesale when adding a new language, only then needing to edit the prose content/text of each.
The problem is now that I'm ready to go live, my web host requires that I have a page called 'index.html' in a directory of theirs (called 'html_public'); this will completely break my page navigation. I can't put all of my language index pages in that directory (because they're all called index.html) and I can't re-name them (e.g., to 'index_EN.html') because of the aforementioned naming requirement.
Must I redesign the whole site? Is this convention common/the rule, or have I just picked the wrong host? If I have just a single (say, English) index page in 'html_public' with all of the others in their respective language directories, then I'm concerned that the content of those other pages might not be indexed. Does anyone have any suggestion about what to do here -- I thought I was structuring this site the right (i.e., simple) way, and now I find that I've got to put twists and turns in to get it online...
If answering, please don't suggest that I just add auto-translation to a single language site -- I'm polylingual, and I've seen how translation software mangles content.
This is common, the server wants an index.html file. A quick and painless solution for you would be to rename your index_EN.html file to index.html and use it as the home for everyone, from there, you can go to the other languages. A more complex but cleaner solution, would be to create an index.php file and in there read the language of the browser visiting your site and redirect to the correct index file.
This should get you started with the php solution Detect Browser Language in PHP
we are developing mobile app using jquery mobile & phonegap for various customers. Almost all the requirement completed but current requirement is each customer expecting different structure of html. how to make this possible satisfy the requirement?
i can duplicate of all pages and change the structure of html based on customers. But it difficult to maintain all these files i think so
in mvc we having partial view to achieve this, we expecting something same like partial view in html.
Thanks in Advance
Here are couple of approaches I have used in the past in different situations, in decreasing order of my personal preference:
1) Use JSP if your pages are going to live on the server and employ #includes to incorporate fragments of reusable JSP in a master page.
2) Use a template engine to place client-specific HTML fragments. You will be interleaving your business rules in the template's query language.
3) Use Jquery if your pages are packaged in a client app and use $.load() to load fragments of HTML. You will have to ensure that you do this before JQM begins its own life-cycle and fires its init events.
4) Use a Ant build script to do a client specific build using Ant's replace and token match tasks. YMMV with this approach based on the complexity of rules you need to check to create a page. Ant is just one option; any other build tool will provide similar function.
You will probably end up using multiple techniques from above for a complete solution.
I'm working with two students to produce a few HTML pages (a homepage and two secondary page layouts) that will later be implemented into a larger CMS.
I'd like to be able to abstract the shared HTML (head metadata, primary navigation, footer, etc.) into separate files so we only have to update them in a single place, execute a shell command to generate new, complete output. Since these pages are only ever going to become templates for another team, I don't even need to integrate any external data sources.
I know Jade would work for this but our partials/layouts/whatever need to look like HTML. I keep coming back to precompiling Handlebars templates but I'm not having much luck getting them to work.
Since we're using Foundation 5, Ruby and Node are already part of our toolchain. Suggestions?
I really like Middleman for this kind of thing. Layouts and partials and local data, etc. Wonderfully useful for doing front-end prototyping for what will eventually become a Rails application.
I have this relatively large web app, it is a single page with ajax calls for the business logic.
Currently I have a small html file that loads all css and js files, and then loads the actual content of the page using ajax, so I have like 15 html files to load a single page (each html file is a "div" in the main html page.
Several files are easier to maintain, but my question is: what is better in terms of performance / User experience?
Keep it as is now (several files loaded async) OR have a script that joins all the files on "compile" time (when deploying)?
I understand that having a single html file is more efficient in terms of network performance, but on the other hand a small file will load faster, and the rest of the content will load after a "loading" dialog.
It is better to have less files as scripts block and load sequentially, or use deferred loading. There is normally a per domain limit for parallel downloads although I cannot for the life of me remember what it is.
For production if you compile a single payload for the scripts together and all of the stylesheets together you will likely reap some performance benefits. I would also consider minifying the output as well. Yahoo Compressor and Google Closure Compiler are two tools that can be used to achieve this.
This will tell you more about the techniques to stop blocking...
http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/
Some performance tips, not limited to JavaScript...
http://developer.yahoo.com/performance/rules.html