I have two packages with several polymer custom elements.
Each package imports the other
One package contains elements that use or derive from the elements in the other package.
The other package uses the elements from the imported package just in the demo pages to make them more appealing.
There are no circular dependencies between elements.
In each package I have a folder 'example' that contains a demo page for each custom element.
I use the transformers configuration in pubspec.yaml and pub build to build the Javascript version of the demo pages.
(Because pub build doesn't yet support the example directory for entry points I created a symbolic link web that points to examples.)
When I execute pub build the examples are built and several of them work fine.
Not all though because there are limitations with transformers:
pub build with transformers doesn't support imported packages that have transformers configured in pubspec.yaml.
So my new approach was as suggested at the Dart web-ui group
I created a new package
The new package imports the two packages with the custom elements.
I symlinked all example files from the two custom elements packages to the web/ and web/src directory of the new package.
When I execute pub build all seems fine but
when I open the demo pages and debug them I see none of the xxxChanged methods of any of the custom elements get called (except when they are called explicitly from enteredView attached or ready).
Other methods like enteredView attached or ready are called though.
A diff between the files (about 14k size) showed several smaller differences but the most (about 98%) are equal.
This generated code (not minified) is not easy to decipher at least not for me and I found no hint what could have caused these differences.
Any Idea what can be the source of that problem?
When I add
transformers:
- polymer:
entry_points:
(without any entry_points)
to the pubspec.yaml of the custom elements packages all works fine in JavaScript too.
EDIT
related issues
generated JavaScript for polymer elements dosn't call xxxChanged for published attributes
add support for global transformers in code_transformers
polymer transformer can only be used on the application package and not on a library package
add support for dev_transformers
Related
I am working with WebAssmbly and Webpack together. My source wasm language is Go. How it works is that there is a webpack load rule that builds and imports the file to my project:
// index.js
import wasm from './main.go'
...
// webpack.config.js
...
rules: [
{
test: /\.go/,
use: ["golang-wasm-async-loader2"],
},
]
...
With watch mode enable, this works absolutely wonderfully for my main.go file. The issue arises when I change any other file. Go compiles all the files in a particular module to a single binary, so I only need to import the main file, and importing other files would just cause it to run multiple times (which I also don't want).
I was wondering if it was possible to force webpack to reload regardless of a file being imported or not?
I looked over at their watch docs however I did not find anything :(.
Thanks :)
Unfortunately, it sees seems that this is impossible to fix from webpack's user api. The only way to fix this is to change how the loader works.
Using The loader API, it is possible to add a context dependency or a generic dependency so that those files are watched for reloads as well :)
I have a code in golang that is using buildmode plugins. I am building the main program and the plugins inside the same image (goboring/golang:1.15.8b5) and one after the other. When running the main program, as soon as it tries to load the plugins, I get the error:
E0319 14:27:38.417362 34123 daemon.go:639] loadVendorPlugins(): fail to load plugin /plugins/my_plugin.so: plugin.Open("/plugins/my_plugin"): plugin was built with a different version of package crypto/internal/boring​
This does not happen if I change the image to golang:1.15. Any idea why a different version for a package is found even if both are built in the same image? Why the base image might have an impact on this?
Apparently, when using the buildmode=plugin, it is not strange to see this problem. The solution is to add the flag -trimpath to the go build, as explained here: https://github.com/golang/go/issues/27751#issuecomment-593082117
I am trying to set up sass with Angular Dart but I'm a bit lost and couldn't find a documentation past 2016 (a good one)
I currently have the following structure:
However I cannot reference a main.css file as it is not found and if in a component I put something like this
styleUrls: ['lib/assets/sass/main.scss']
The webdev serve command fails
My pubscpec is
dependencies:
angular: ^5.0.0
angular_components: ^0.9.0
bootstrap_sass: any
dev_dependencies:
angular_test: ^2.0.0
sass_builder: ^2.1.1
build_runner: ^0.10.0
build_test: ^0.10.2
build_web_compilers: ^0.4.0
mockito: ^3.0.0
test: ^1.3.2
I cannot figure out what's wrong and also the structure I should use
Should I put in my top component main.scss (or the compiler main.css) and do not set any other file reference or should I include it at every component? And also how can I generate this compiled file when I run webdev serve
Thanks,
Alexi
So the references for styleUrls should always be the compiled css not the Sass file. Also the Urls need to be either relative to the file, or package format. So either 'main.css' or 'package:your_project/assets/sass/main.css'
I would also suggest not having separate asset directories. I tend to find having the sass file next to the component to be easier to maintain.
AngularDart also has style encapsulation by default; meaning CSS won't leak outside of the Components by default. Given this I find it better to have the CSS local to that component and be next to that component. You'll find that is the pattern on the angular components, and gallery.
One small note on the components, and gallery. They use the pattern style.scss.css instead of style.css which breaks the convention of Sass. The reasoning behind it is so that we can quickly tell what the source of the CSS file was. Was it written by hand, or did it come from Sass. This is achieved by having different settings in the build.yaml file. I don't think you should do this for your project tho.
I'm writing an iOS application in Swift, and I'm trying to figure out how to organize the project into separate modules. I'm using an MVVM architecture, and I want to make the Model, ViewModel, and View components separate Swift modules that make only subsets of themselves accessible to the modules that import them. The files in the View would import the ViewModel, and files in the ViewModel would import the Model. How can I accomplish this? Note that I'm not trying to create libraries that multiple applications can share. I'm just trying to enforce separation of components using modules.
EDIT: Maybe the question is, "What mechanism should I use to create modules aside from the one that comes with the initial iOS application project?"
One of the answers in "How do you use Namespaces in Swift?" https://stackoverflow.com/a/24032860/215400 says, "classes (etc) are implicitly scoped by the module (Xcode target) they are in." From that, one might conclude that targets correspond to modules and that the answer is to create separate targets within an Xcode project, but I tried that earlier, and tskulbru is saying that I need multiple Xcode projects.
Regarding multiple Xcode projects, the File > New > Project > iOS Framework & Library > Cocoa Touch Framework option didn't look right because it's supposed to be for things that use UIKit, and two of the modules I want to create shouldn't depend on UIKit. The other "Framework & Library" option, Cocoa Touch static library, isn't an option with Swift.
Another StackOverflow post mentioned using private Pods. After spending an hour working on that, I concluded that it wasn't the right solution because I shouldn't have to edit these modules in different workspaces.
This isn't possible without creating separate projects for the modules you want to create. This is because the way Swift handles namespacing.
Eonil answered this better than me: https://stackoverflow.com/a/24032860/215400
(Copy below)
Answered by SevenTenEleven in the Apple dev forum:
Namespaces are not per-file; they're per-target (based on the
"Product Module Name" build setting). So you'd end up with something
like this:
import FrameworkA
import FrameworkB
FrameworkA.foo()
All Swift declarations are considered to be part of
some module, so even when you say "NSLog" (yes, it still exists)
you're getting what Swift thinks of as "Foundation.NSLog".
Also Chris Lattner tweeted about namespacing.
Namespacing is implicit in swift, all classes (etc) are implicitly
scoped by the module (Xcode target) they are in. no class prefixes
needed
From my perspective if you want to encapsulate your components, probably you have two solutions:
Framework
Internal cocoapods
Both solutions will give you fully encapsulated modules, where you can define API that will be available in project through public keyword.
All other things will be not visible in your core project.
Managing your project will cost you a lot more time, but if you write this using SOLID principles, probably you will get more reusable code and those frameworks could be imported to other project just using import definition.
I want to add my own project type based on IronStudio. So,
I downloaded the source for and compiled the latest version of IronPython, then
I created a new Visual Studio Package.
I added the Templates\Projects\MyProject folders, and added a file to it, and set its property "Include in VSIX" to true.
Then modified the main Package class to be derived from IronStudio's PythonProjectPackage instead, and set the ProvideProjectFactory property:
[ProvideProjectFactory(
typeof(PythonProjectFactory),
"Django Project",
"Django Project Files (*.myproj);*.myproj",
"myproj", "myproj",
#"Templates\Projects\MyProject",
LanguageVsTemplate="MyProject")]
public sealed class MyPackage : PythonProjectPackage
And ran it. But MyProject isn't showing up in the project templates. Why not?
The generated .pkgdef file looks like this:
[$RootKey$\InstalledProducts\VSPackage3Package]
#="#110"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{5cd7435c-7461-459f-80bc-c0c79e9d462f}]
#="Microsoft.VSPackage3.VSPackage3Package, VSPackage3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a4f1577d825253f8"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.VSPackage3.VSPackage3Package"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}]
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\Extensions]
"py"=dword:00000020
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a701-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a702-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a703-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\CLSID\{888888fd-3c4a-40da-aefb-5ac10f5e8b30}]
#="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
"ThreadingModel"="Both"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="My Project"
"DisplayProjectFileExtensions"="My Project Files (*.myproj);*.myproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="myproj"
"PossibleProjectExtensions"="myproj"
"ProjectTemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
"Language(VsTemplate)"="MyProject"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="My Project"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="IronPython"
"DisplayProjectFileExtensions"="IronPython Project Files (*.pyproj);*.pyproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="pyproj"
"PossibleProjectExtensions"="pyproj"
"ProjectTemplatesDir"="$PackageFolder$\.\NullPath"
"Language(VsTemplate)"="IronPython"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="IronPython"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\.\NullPath"
[$RootKey$\Services\{b98e41c4-581e-3532-beee-06829b683d39}]
#="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"Name"="IPythonStarter"
I just want to get the bare bones up and running so I can start overriding some functionality (like the Add New Item dialog).
Update:
Reading my initial analysis once again increases my impression that some of the required components are missing (e.g. a dedicated ProjectFactory) and/or wired up incorrectly - from the MSDN documentation of the ProvideProjectFactoryAttribute Class:
ProvideProjectFactoryAttribute declares that a package provides a project factory.
And further:
If a VSPackage declares that it provides a project factory, it should create the factory and offer it to Visual Studio in the Initialize method of the Package-derived class.
You package is declaring to provide PythonProjectFactory, but (likely) doesn't offer it to VS, rather it is offered by the IronPython package. In turn you are providing arguments within the ProvideProjectFactory attribute list which PythonProjectFactory won't know about when asked for by VS.
Consequently you should at least provide a dedicated ProjectFactory yourself as per the walkthrough, wire up the classes accordingly and see how this turns out regarding the issues outlined below.
Initial analysis:
There appear to be several issues here at first sight - have you followed any tutorial on how to do this? In case, please note that some of those easily discoverable via search engines are outdated still. Either way I'd try working through and/or comparing your result with Walkthrough: Part 1 - Creating a Basic Project System from the MSDN documentation for VS 2010; please note that even this one is claimed to be outdated a bit according to the Community Content section on the bottom of the page.
Here is what I'd look into myself given the code you present, comparing with the walkthrough on the fly for more insights:
You realized already that the duplicate fragment starting with the GUID above PythonProjectFactory doesn't make sense - this is essentially trying to register two packages at once, which, even if allowed at all syntactically (which I doubt), can't possibly work like so due to both being registered with the same GUID [cross checking with the sample file in section Examining the Template Registration confirms this suspicion, as expected there is only one such fragment].
Please note that the GUID in question is the one identifying PythonProjectFactory (as per the respective source code), see below for more on this.
[Guid(PythonConstants.ProjectFactoryGuid)]
public class PythonProjectFactory : ProjectFactory {
Given .pkgdef is a generated file the next question is where this duplication/violation stems from. When two generated artifacts end up with the same GUID the respective definition in the sources is most likely messed up somehow, usually due to copy&paste duplication. Consequently you should verify whether {5cd7435c-7461-459f-80bc-c0c79e9d462f} is defined and referenced as intended, though here might be one or two other causes as well for this, see below.
A Package class needs to be identified by a GUID and the VS wizard generates some already in Guids.cs and references it accordingly on the class definition, however, the following is missing in your fragment [cross checking with the sample fragment in section To register the project template confirms this omission as well]:
[Guid(GuidList.guidMyPackagePkgString)]
public sealed class MyPackage : Package
Likewise it appears incorrect to derive MyPackage from PythonProjectPackage but reference PythonProjectFactory still rather than providing MyFactory as well (including a dedicated GUID), because the latter tells Visual Studio the location of your project template folder [see section Creating a Skeletal Project Factory]:
While it might well be possible to simply reuse all functionality from the base class PythonProjectFactory, inheriting is likely required simply because the factory must have a dedicated GUID too (as outlined in the walkthrough) in order to properly wire up the attribute specified data.
Likely unrelated, but still suspicious is that your two code blocks don't relate, as the Package class definition specifies Django Project Files (*.myproj);*.myproj, yet the result shows My Project Files (*.myproj);*.myproj.
Have you by chance mixed this from different builds or is this really a result of a clean one?
Good luck!
This stackoverflow posting might be helpful: VS2010: VSIX installation doesn't deploy item templates inside it
If this is not what you're looking for, try to see if you're missing something around the creation of custom project templates, I believe that's where the "missing link" is:
For VS 2008:
http://blogs.msdn.com/b/webdevelopertips/archive/2008/12/02/tip-32-did-you-know-how-to-easily-create-your-own-project-templates.aspx
For VS 2010:
http://blog.reybango.com/2010/09/21/how-to-create-html5-website-and-page-templates-for-visual-studio-2010/
and on MSDN:
http://msdn.microsoft.com/en-us/library/s365byhx.aspx
and here is how to create a project
template manually:
http://msdn.microsoft.com/en-us/library/ms185291.aspx
and here is how to create a new item template in VS 2010: http://msdn.microsoft.com/en-us/library/ms247113.aspx
Hope this helps
$PackageFolder$.\NullPath may have something to do with it.