What is the correct order to include lit-elements into my script? - custom-element

Let's say I have this HTML:
<outer-element>
<inner-element></inner-element>
</outer-element>
inner-element and outer-element are custom elements extended from LitElement.
Is there a prescribed order to include the files defining these elements into my script?
E.g.
A.
import './inner-element.js';
import './outer-element.js';
vs
B.
import './outer-element.js';
import './inner-element.js';
I've noticed that the order of inclusion determines the order that the elements are rendered. That is, A leads to render() being called on the inner and then the outer. Whereas B leads to render() being called on the outer and then the inner.
A live example, where you can switch the order and see the result in the console is provided here.
My (naive) intuition was that the render order would be determined by the structure of the HTML page. Instead, it appears to be determined by the order of Javascript includes. Which makes me want to know: Is an order that is considered correct?

From the HTML parser stand point, the order considered as correct should be the order of appearance of the elements (your intuition).
But from the Javascript execution viewpoint... it depends on the author and developer intentions.
Generally, unless you are both the author and user of the custom element, you cannot know whether a custom element is defined before or after it is parsed, nor the order in which 2 different elements are defined.
Therefore, as a web components author, you should try to develop custom elements whose rendering is not dependent the definition order (as much as possible). Otherwise make it clear in the documentation.
As a web components consumer/user, you should be aware (and you are aware) of the side effects of asynchronous download and deferred defintion of scripts and modules.

Related

Vue.js components - handling translations within a component library from a consuming project without repetition

I fully expect this is a little niche, and I'm not sure if there's a solution, but I have an interesting situation.
We have a library of Vue components we use in our projects, from form fields to data tables. Some of these components need aria labels, buttons, labels, messages, and so on. Most of our projects will need translating into any number of languages, on the fly, often via user-selectable drop-down menus. Translation is handled by Vue i18n.
I have begun adding slots and props as required to allow this translation, but I realise it's going to be a lot of repetition to use the components, as it will be necessary to translate them each time they are used, some of which may be used hundreds of times in a large project.
The components are part of a library which has no knowledge of any current translation, and won't have access to the translated strings.
What I'm wondering is if anyone has an idea for how to essentially say 'here are some default slots and props for this component, which will override the defaults set in the component itself, but will apply every time I use this component in this project unless otherwise stated'.
I can't make these the defaults in the component itself, as what the default will be differs from user to user.
The only two thoughts I've had are:
Somehow passing the instance of the vue-i18n plugin to the components as they're used, allowing them to find their own translation strings.
Creating 'wrapper' components which are part of the current project, and thus do have access to translations, which can set a lot of these repetitive props and slots for us. This seems pretty reasonable, but doesn't solve where some components use others (e.g. our form components can be used by themselves, or initialised by a form builder, which then wouldn't know to use the 'middleware' components)
Am I missing an obvious solution?

Zope 2: What's the difference between "template" and "view"?

I know, it's a naive question :-)
Originally poped up into my mind over Zope 2: How to properly “browser:page” to make a page available everywhere?
Views are callable adapters that provide output based on the context and the request.
Templates are callables that render a piece of text based on a template. They are often used in views.
Note that views can return text without using a template:
from zope.publisher.browser import BrowserView
class MyView(BrowserView):
def __call__(self):
return "Hello world, I am located at {0}".format(self.context.absolute_url())
Views can also be used by other Zope code, without themselves being published. Zope code uses a lot of views internally.

Knockout in Rails 3

if I'm using rails 3 which uses asset pipeline to compile all
Javascripts, does that mean I can have only one Knockout view model for my entire application? If not, how do I specify which view model is binded with which view? In the tutorial code, it looks like 1 view model is bound per page, but that doesnt work in rails since all JS are loaded upon first page load.
No, you do not need to include all javascript on every page! This is a very bad idea.
There are many methods for limiting javascript to a single page, you should pick one:
Method 1
Method 2
Method 3
Please, please, please do not try to load all your javascript on every single page.
Update (after your comment below):
I think you are confusing a few different things here.
First, even if you compile all your javascript into a single gzipped/uglified file, that still doesn't force you to use one knockout viewmodel for your entire application. That file can contain multiple viewmodels. They don't even need to know about each other.
Second, the way the rails pipeline works is by concatenating related or dependant javascript files together. It does this to reduce the number of requests the browser has to make to get the javascript it needs for each page. It doesn't necessarily mean all your javascript becomes one file. Just that the javascript for each page become one file. For more information, check out the Rails Asset Pipeline Documenation, it has a great explanation of how it works and how to use it properly.
Third, neither of these things mean you need to write all your javascript as if it were one file. In fact, this is a bad idea. You should seperate your javascript into relevant files by functionality. This allows them to be reusable, as well as eases development work.

JSF2: Building JSF2 views (whole component trees) at runtime

Currently I'm trying JSF 2.0 and still learning the more advanced features.
JSF2 is comfortable when having to deal with pre-defined views (fixed component trees) whose widgets are completely known at compile time -- of course with the exception of repeating data list/table entries and light dynamic modification of forms via the DataTable "trick" (as I read here, especially under JSF2, can I add JSF components dynamically? and How to create dynamic JSF 1.2 form fields).
Now I'm wondering about the realization of completely dynamic JSF2 component trees, where a web user, for each given content type (e.g. 'Person', 'PersonList' but also 'PersonalManagementPanel'), can choose one from a list of content-type compatible widgets (=JSF custom components).
As result, this user will always see the "Personal Manager Page" rendered with his/her prefered "PersonalManagerPanel", which in turn also renders its nested components ('Person', 'PersonList') with the user's preferred variants.
Obviously, the goal is to get a selectively configurable/customizable JSF Page -- at runtime.
Is this scenario realizable in JSF2? -- How could this be done?
Are there more appropriate Java technologies for this requierement?
-- One possible alternative I'm thinking of is XML plus XSLT.
Thank you very much for your help and suggestions.
Best regards
Martin
You can use something like this:
<ui:include src="#{bean.template}" />
Or if you want more complicated components, you should take a look at the PreRenderViewEvent.
Note that there are issues with both solutions.
http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-770
http://java.net/jira/browse/JAVASERVERFACES-1708
http://java.net/jira/browse/JAVASERVERFACES-2041

How to generate navigation tree in doxygen output?

If you've used javadoc and then come to doxygen, you may know what I mean when I say I miss the hierarchical (frame-based) view that made jumping from class to class and method to method easy. (For those who haven't seen it, imagine a tree-navigator in an IDE or over a filesystem).
How can I get Doxygen to include a navigation tree, if it's even possible?
A similar question was asked in October, but that was just about stylesheet alternatives and only one turned up. I think I'm looking for something more major.
Note that all you need to do to get the tree on the left in Quinn's example is setting GENERATE_TREEVIEW to YES in the config file.
At a basic level, Doxygen output is what it is, and I don't think there's "a better way to view" static HTML content. I think what you want is for Doxygen to produce HTML output that is more similar to Javadoc, which has both pros and cons. (The biggest drawback is that it's unlikely to happen, due to the effort involved and the broad user base.)
I manage a project that is documented using Doxygen, and I'm not sure to what degree my config uses the Doxygen defaults, but I get a sections in the left frame for a flat class list and a class hierarchy. Also, since I have diagrams enabled, the Graphical Class Hierarchy is a fairly quick way to jump to where I want. I haven't delved into Doxygen modules, so I don't have any experience with whether that might segment things similar to how Javadoc does with packages.