During the Web Applications WG (WebApps) Web Components meeting in Mountain View CA US on Friday 24 April 2015, it was concluded that support multiple shadow roots should be removed. As I understand it, slots are supposed to be used as an alternative to using multiple shadow roots. However, the link provided in the meeting notes explaining the reasoning why using slots is better has been removed and I could not find any other documentation on how and why this decision was made. I suspect that it has to do with the confusing nature of handling multiple shadow roots, but I'm not sure. I would appreciate any explanation of the reasons why support for multiple shadow roots removed.
TLDR; What reasons were given for removing support for multiple shadow roots and requiring the use of slots instead.
It's because it was complex to implement.
From the W3C Web Components wiki:
Pros: enables consistent story for adding shadow trees to builtins /
provides
reasoning about subclassing DOM trees
Cons:
complexity /
performance: may result in "submerged" trees that aren't rendered but
still participate in style/layout
Cost/benefit of change:
Disables the use case for general inheritance-based component
composition and Firefox UI in XBL) / Makes implementing Shadow DOM
easier
Related
In this article on views (https://code.kx.com/q/learn/views/) it is explicitly stated that views should not contain side effects.
However, in this article (https://code.kx.com/q/style/sam/) it is stated "SAM is an abstract model of q applications. Think of SAM as having an inner core and an outer layer. The inner core of SAM consists of variables and constants interconnected by views. All functions, and all views expressed in terms of them are completely free of side effects. All side effects in the core are explicitly located in views."
These 2 statements seem to conflict. Which is correct?
Trust the article on views.
Apologies for the confusion. The SAM article was adapted from a 1995 paper “Remarks on Style” written by Stevan Apter, and should probably have been omitted, as were sections on windowing. The style ‘remarks’ would be better hosted at GitHub.com/qbists and maintained by the community; I’ll see about moving them there.
Update 2023.02.10 Remarks on Style now moved to GitHub qbists/style, with a new section on trailing semicolons.
While the source for this material has long been on GitHub and open for contribution, I’m hoping hosting it in Qbists will attract more content. For example, what is good style with tables? With IPC?
Comments to librarian#code.kx.com; PRs to
I currently have a Web API project which currently has all the system processing in the same solution. I'm breaking this out into separate solutions so that they can be ran independently (e.g. an Azure WebJob) as I don't want to have to redploy the Web project if something in the backend has changed.
My issue with this is that even though I have separated the logic they are tied together by a single context so that if I make a change in one I will have to redeploy all as the migrations won't match up.
So that's why I've been looking at Bounded Context and DDD. I'm looking at how to break this up but having trouble understanding how relationships work.
A lot of the site is administrative (i.e. creating entities, no actual processing) so was going to split contexts around this e.g.:
A user adds and maintains currency conversion rates (this is two entities in
total).
A user adds and maintains details on how to process payments (note that is is not processing payments, it only holds information about paypal account details etc).
So I was splitting the context's up by this, does this sound reasonable to start with (there are a lot more like this such as tax bands, charge structures etc)?
If this is the way to go, how do I handle relationships between those two contexts? As an example:
A payment method requires a link to an 'active' currency conversion. I understand I can just have this as an Id, but I need to check it's state so need access to the model.
A currency conversion can only be set to 'Inactive' if there are no payment methods currently using it. Again this needs access to the other model.
So logically the models need access to each other, how would this be included in the context? Can I add navigation properties to a model in a different context? Or should I add it as a separate DbSet and possibly map using a view?
Thanks
So I was splitting the context's up by this, does this sound
reasonable to start with (there are a lot more like this such as tax
bands, charge structures etc)?
"So that they can be ran and deployed independently" may not be a sufficient heuristic to tell when you should split Bounded Contexts. This addresses one aspect of the solution space, but if you haven't looked well enough at the problem space, you'll suffer from a misalignment between BC's and subdomains that can cause a lot of friction. You might end up always deploying a cluster of seemingly unrelated "independently deployable units" together because you didn't realize they talk about the same thing.
Identifying subdomains is the product of distillating your business - separating the big functional areas and defining which parts are your core domain and which are ancillary activities. Each subdomain has its own specific semantics (Ubiquitous Language). In your case, as has been pointed out in the comments, Currency Conversion and Payment Methods might well be part of the same subdomain (Payment?). It does not automatically mean that they should also be in the same BC but it might be a good idea to keep subdomains aligned 1-to-1 with BC's, as additional BC's come at a cost.
Back to deployability, even if it can be one beneficial effect of Bounded Contexts, they are not always so easily translatable in terms of independent units of deployment. Context mapping patterns (Shared Kernel, Customer Supplier, etc.) and BC communication in general can lead to a model, and therefore a part of a codebase, being shared by multiple BC's. Code and API synchronization issues arise that can question a simplistic "deployable free electron" view.
Just because you're using the Bounded Context approach doesn't mean you have to use DDD's tactical patterns (Aggregate Root, invariants, etc.) inside each BC. Using them should be an educated decision to trade solution space complexity off for problem space manageability. If "Currency Conversion can only be set to inactive..." is the only rule pertaining to payment method and currency management in your business, it might not be worth the bother to give that Bounded Context a full-fledged rich domain model. CRUD could be better suited there.
Can anyone explain if there are any significant advantages or disadvantages when choosing to implement features such as authentication or caching etc using hooks as opposed to using middleware?
For instance - I can implement a translation feature by obtaining the request object through custom middleware and setting an app language variable that can be used to load the correct translation file when the app executes. Or I can add a hook before the routing and read the request variable and then load the correct file during the app execution.
Is there any obvious reason I am missing that makes one choice better than the other?
Super TL/DR; (The very short answer)
Use middleware when first starting some aspect of your application, i.e. routers, the boot process, during login confirmation, and use hooks everywhere else, i.e. in components or in microservices.
TL/DR; (The short answer)
Middleware is used when the order of execution matters. Because of this, middleware is often added to the execution stack in various aspects of code (middleware is often added during boot, while adding a logger, auth, etc. In most implementations, each middleware function subsequently decides if execution is continued or not.
However, using middleware when order of execution does not matter tends to lead to bugs in which middleware that gets added does not continue execution by mistake, or the intended order is shuffled, or someone simply forgets where or why a middleware was added, because it can be added almost anywhere. These bugs can be difficult to track down.
Hooks are generally not aware of the execution order; each hooked function is simply executed, and that is all that is guaranteed (i.e. adding a hook after another hook does not guarantee the 2nd hook is always executed second, only that it will simply be executed). The choice to perform it's task is left up to the function itself (to call out to state to halt execution). Most people feel this is much simpler and has fewer moving parts, so statistically yields less bugs. However, to detect if it should run or not, it can be important to include additional state in hooks, so that the hook does not reach out into the app and couple itself with things it's not inherently concerned with (this can take discipline to reason well, but is usually simpler). Also, because of their simplicity, hooks tend to be added at certain named points of code, yielding fewer areas where hooks can exist (often a single place).
Generally, hooks are easier to reason with and store because their order is not guaranteed or thought about. Because hooks can negate themselves, hooks are also computationally equivalent, making middleware only a form of coding style or shorthand for common issues.
Deep dive
Middleware is generally thought of today by architects as a poor choice. Middleware can lead to nightmares and the added effort in debugging is rarely outweighed by any shorthand achieved.
Middleware and Hooks (along with Mixins, Layered-config, Policy, Aspects and more) are all part of the "strategy" type of design pattern.
Strategy patterns, because they are invoked whenever code branching is involved, are probably one of if not the most often used software design patterns.
Knowledge and use of strategy patterns are probably the easiest way to detect the skill level of a developer.
A strategy pattern is used whenever you need to apply "if...then" type of logic (optional execution/branching).
The more computational thought experiments that are made on a piece of software, the more branches can mentally be reduced, and subsequently refactored away. This is essentially "aspect algebra"; constructing the "bones" of the issue, or thinking through what is happening over and over, reducing the procedure to it's fundamental concepts/first principles. When refactoring, these thought experiments are where an architect spends the most time; finding common aspects and reducing unnecessary complexity.
At the destination of complexity reduction is emergence (in systems theory vernacular, and specifically with software, applying configuration in special layers instead of writing software in the first place) and monads.
Monads tend to abstract away what is being done to a level that can lead to increased code execution time if a developer is not careful.
Both Monads and Emergence tend to abstract the problem away so that the parts can be universally applied using fundamental building blocks. Using Monads (for the small) and Emergence (for the large), any piece of complex software can be theoretically constructed from the least amount of parts possible.
After all, in refactoring: "the easiest code to maintain is code that no longer exists."
Functors and mapping functions
A great way to continually reduce complexity is applying functors and mapping functions. Functors are also usually the fastest possible way to implement a branch and let the compiler see into the problem deeply so it can optimize things in the best way possible. They are also extremely easy to reason with and maintain, so there is rarely harm in leaving your work for the day and committing your changes with a partially refactored application.
Functors get their name from mathematics (specifically category theory, in which they are referred to a function that maps between two sets). However, in computation, functors are generally just objects that map problem-space in one way or another.
There is great debate over what is or is not a functor in computer science, but in keeping with the definition, you only need to be concerned with the act of mapping out your problem, and using the "functor" as a temporary thought scaffold that allows you to abstract the issue away until it becomes configuration or a factor of implementation instead of code.
As far as I can say that middleware is perfect for each routing work. And hooks is best for doing anything application-wide. For your case I think it should be better to use hooks than middleware.
This has baffled me for a long time.
Given basic atomic primitives like compare & swap, I can see how to implement a spin lock (from which I can build mutexes).
However, I don't see how I can build condition variables out of this. How is this done?
It's not particularly simple. The following is a link to a paper by Douglas Schmidt (who is also largely responsible for the ACE libraries) that details several approaches for implementing condition variables on Windows using the synchronization primitives available in Win32 (pre-Vista). The approaches include using only the basic, generally available on any OS primitives, and discusses the various limitations of the approaches:
http://www.cs.wustl.edu/~schmidt/win32-cv-1.html
The bottom line (concluding remarks):
This article illustrates why developing condition variables on Win32 platforms is tricky and error-prone. There are several subtle design forces that must be addressed by developers. In general, the different implementations we've examined vary according to their correctness, efficiency, fairness, and portability. No one solution provides all these qualities optimally.
The SignalObjectsAndWait solution in Section 3.4 is a good approach if fairness is paramount. However, this approach is not as efficient as other solutions, nor is it as portable. Therefore, if efficiency or portability are more important than fairness, the SetEvent approach described in Section 3.2 may be more suitable. Naturally, the easiest solution would be for Microsoft to simply provide condition variables in the Win32 API.
Note that starting in Vista, Windows supports condition variables using native APIs:
http://msdn.microsoft.com/en-us/library/ms686903.aspx
I am looking for tools to aid in the visualization of custom business logic used to perform document generation. The logic is expressed as an object-oriented model consisting of a graph of decision points and rendering actions. The basic building blocks are relatively simple, but the overall decision tree is quite large and complex making it hard to visualize.
We are looking for suggestions on tools and/or graphing libraries that can be used to visually represent the decision tree and rendering actions. The choice of programming language is not critical (Delphi, C#, Java would be great) and we are able to easily extract the logic to XML or other data format as required. The preference is for something that will run under Windows and enable printing or PDF output of portions of the resulting diagram.
Requirements
Decision points can be simple yes/no or multiple outputs e.g. (yes, not, sometimes, always etc).
The decision points are linked to external business logic that exist elsewhere in the runtime environment. We need to label the graph node with the type of decision point (e.g. boolean) and string describing the business rule being used.
Rendering actions are linked to named content objects with optional merge variables and inline rendering logic. At a minimum we need to be able to label nodes with the name of the element and ideally also information about variables used to render the content.
We have considered building something around Visio or WinGraphViz, or perhaps using a third-party graphing/flowchart library. Any ideas or pointers would be greatly appreciated.
After some more digging I found WinGraphViz and DotXML to be the closest match to my requirements. I was previously unaware of the "record" element which allows me to render decisions in the logic flow in a clean and legible manner.
You can consider Morphir with the Elm frontend.
It is a solid tool for business logic modeling, and code generation.
Visualization is coming along as well.