What happens when using multiple in the #Source annotation of a CssResource in a ClientBundle? Is this compatible with using #External/#CssResource.NotStrict?
To be more specific - in our codebase I encountered a ClientBundle that contains something like this:
#Source({"style1.css", style2.css"})
#CssResource.NotStrict
CustomCss css();
This suggests that definitions in style2 can override definitions in style1. Should this also work when using #CssResource.NotStrict, so without the accessors and obfuscation?
When #Source has multiple values, it's equivalent to concatenating the files (in order) into a big stylesheet. This is mostly useful to import constants (#def, #eval or #url) or #externals.
It doesn't change anything to the behavior or #external (note: that means one file can declare as #external a class name used in another file) or #NotStrict.
Related
I use Telosys (https://www.telosys.org) to generate Python source code and it works fine. But I have a specific need that could be solved by calling a specific conversion function.
Is it possible to create a specific function and to call it inside a Telosys template?
For example: myFunction(“abc”) or $something.myFunction(“abc”) or anything else
If necessary it's possible for me to create this function in different languages like Java, Python or JavaScript.
Telosys is designed to be extensible, so yes you can create your own functions and call them in your templates.
As Telosys is written in Java you will have to create these functions in Java, then use the "loader" object in the ".vm" file to load your class and call the methods defined in this class.
Here's how to do that step by step:
Use your preferred IDE to create a Java class defining your specific method(s). This class can be in any package (including the "default / unnamed package"), the method(s) can be "static" if you don't need an instance of the class.
Compile this class (the goal is to produce a simple ".class" file or a ".jar" file if you prefer)
Put the class (or the jar) in the templates bundle folder :
if you have a ".class" file put it in "classes" folder
if you have a ".jar" file put it in the "lib" folder
Examples :
TelosysTools/templates/my-bundle/classes/MyClass.class
TelosysTools/templates/my-bundle/lib/my-lib.jar
In the template file (".vm") use the "$loader" object to load your Java class and call any of its methods
See "$loader" reference here : http://www.telosys.org/templates-doc/objects/loader.html
If all your methods are “static” you don’t need an instance so just use “$loader.loadClass()”. Example :
## load the class and keep it in a new “$Math” object (no instance created)
#set( $Math = $loader.loadClass("java.lang.Math")
## use the static methods of this class
$Math.random()
If your methods are not “static” so you need an instance, then use “$loader.newInstance()”. Examples :
## create an instance of StringBuilder and put it in the context with #set
#set( $strBuilder = $loader.newInstance('java.lang.StringBuilder') )
## use the instance to call a method
$strBuilder.append('aa')
## create new instance of a specific class : MyTool.class
#set( $tool = $loader.newInstance('MyTool') )
## use the instance to call a method
$tool.myFunction()
So to sum up, you can use any class provided by Java-JRE (eg "Math", “StringBuilder”), you can reuse existing libraries by adding a “.jar” file (don't forget to add dependencies required if the jar file is not stand-alone) or just add a single “.class” file.
I am developing a package for Flutter Apps
There are methods and classes that are useful only for the package itself, and not for the programmer who will import my package, is possible to hide this methods and classes for further implementation?
Example:
DataService.dart
export class DataService{
//Must be visible only for my library
static notifyDataChanged(InternalEvent internalEvent){ ... }
//Must be visible for anyone
static addCallbackOnDataChange(onDataChangeCallback) { ... }
}
InternalEvent.dart
//Must be visible only for my library as well
export class InternalEvent {
...
}
The usual approach to having package-only declarations is to put them in a library in the lib/src/ directory, and not export that library. The other libraries in the package can import the package-only library, but users outside the package are discouraged from importing libraries in lib/src/ directly. (It's not impossible, just something that's discouraged because the package is free to change those libraries without warning).
If the package-only features require access to library private parts of public classes, then they need to be in the same library. The traditional way is then to declare both in a library in lib/src/ and export only the parts of that library which needs to be public:
library myPackage;
export "src/allDeclarations.dart" hide Private, Declarations;
// or, preferably,
export "src/allDeclarations.dart" show Public, Things;
Generally you should only put exported and non-exported declarations in the same library if absolutely necessary. Otherwise the hide/show lists become too cumbersome and it's to easy to forget a declaration in a hide list.
You have a few possibilities:
Making a method/variable private, by prefixing it with _:
class _InternalEvent {}
Use the hide/show directives:
// lib/src/event.dart
class InternalEvent {}
class VisibleEvent {}
// lib/my_package.dart
export 'src/event.dart' hide InternalEvent;
OR
export 'src/event.dart' show VisibleEvent;
For package-private members exists an annotation, #internal.
Using #internal the analyzer emit a warning when:
you export the annotated element (from a file under lib)
a consumer of your package imports the annotated element
Anyway, Dart seems to me to make things really complicated. The need to have members who are neither completely public nor inaccessible from outside the file is elementary, yet no solution provides certainties.
Note that:
the doc says to keep the package-private elements in files under lib/src, yet the consumers of your package will still be able to import them, without even the analyzer producing a warning; it's just a convection;
using the #internal annotation, the analyzer (ie the ide, which rely on the analyzer) produces a warning, but nothing prevents you from compiling the code anyway. The situation improves a little if you increase the severity level of the warning produced by the analyzer when the annotation is not respected. To do this, you need to create an analysis_options.dart file like the following:
analyzer:
errors:
invalid_use_of_internal_member: error #possible values: ignore, info, warning, error
Note that the #internal annotation, like other similar ones (#visibleForTesting, #protected) is part of the meta package, which is included in the Flutter Sdk, but which must be included as a dependency in pure-dart packages.
its so simple
suppose i have a below code in src folder of your lib,
class myClass1 {}
class myClass2 {}
class myClass3 {}
below export statement will make all 3 classes visible/accesible
export 'src/mylib_base.dart' ;
below export statement will make myClass3 visible/accessible and remaining not accessible
export 'src/mylib_base.dart' show myClass3 ;
below export statement will make myClass3 not visible/accessible and remaining accessible
export 'src/mylib_base.dart' hide myClass3 ;
So simply
with hide classes/function ,hide those that you mention and remaining will be shown to end user
with show classes/function ,show those that you mention and remaining will be hide to end user
If you are defining an Editor in GWT using the UiBinder, then you can specify the path to a property value using the #Path annotation.
If you are defining an Editor without using the UiBinder (i.e programmatically), how can you specify the path to an editable attribute without using the annotation?
You can use the same #Path annotation on the declared fields.
It is not bound to UiBinder.
You can bind properties to fields in 2 ways -
1) Declare the field with the same name as the property.
2) #Path annotation, in case, if the field and the property are declared with different names.
If you don't want to bind any property to the field, declare that field with #Ignore annotation.
These annotations are all used by Editor Framework's Code generator to generate some supporting java classes.
So, At Runtime you can not change the Path of the editors programmatically.
If you define your UI programmatically, you can still use #Path (or just name the field to match the property) on a field in your widget class. Not using UiBinder doesn't mean you can't use the Editor Framework.
That said, paths cannot be defined programmatically, no matter how you build the ui. The Editor Driver generating code requires that it can see which properties will be used so it only generates the necessary code to wire properties into editors.
Editor and UiBinder are totally distinct features - it just so happens that both can wire into fields in your class. UiBinder doesn't care about #Path annotations any more than Editors care about #UiField
Is it correct to require_once?
where and how would you put it include path?
Should it not be in a application.ini or bootstrap?
EXAMPLE:
require_once 'Zend/View/Helper/Abstract.php';
// #question - is this correct - where and
// how would you put it include path
class Zend_View_Helper_Translate extends Zend_View_Helper_Abstract
{
}
Generally speaking, you can avoid require_once calls almost entirely by appropriately using Zend_Loader_Autoloader. Of course, the key is "appropriate".
Typically, your public/index.php sets the include_path to be the library folder. Then, if you are using Zend_Application, the Zend_Loader_Autoloader is registered to find any PSR-0 compliant classes whose namespace prefixes have been registered using the autoloadernamespaces array in application/configs/application.ini.
The tricky part is for classes defined in files that don't "reside on the include_path", like models that appear in application/models, services that reside in application/services, etc. Even though the classes defined there tend to follow PSR-0 standards, the fact that the PSR-0 mapping occurs relative to a base off the include-path means that the system has to know the mapping between classname prefixes and base paths. This is where resource autoloaders come in. These resource autoloaders are typically set up automatically in the application Bootstrap extending Zend_Application_Bootstrap_Bootstrap and module bootstraps that extend Zend_Application_Module_Bootstrap.
View helpers are another example of classes that reside "off the include_path", perhaps in something like application/views/helpers. Since these are typically invoked in a view script using a short form $this->someHelper($someParam), the system must be told how to generate the fully qualified classname from this short name. This is accomplished using $view->addPrefixPath() which maps namespace prefixes to filesystem locations. Again, the app-level and module level bootstrapping mechanism sets most of these up for you.
For libraries/classes that do not follow PSR-0 standards, you can create custom autoloaders and attach them (typically at Bootstrap) to the Zend_Loader_Autoloader singleton. This is the only place where you would have an explicit include/require.
tl;dr: With proper use of the existing ZF autoloader mechanism, you almost never need to have include/require statements in your own application code.
It is not correct in this case.
First off, please use Zend Tool. It will create the files you don't know how to create yourself. It will create the correct class names, extend them appropriately and require_once anything that might be needed.
Do not place require_once in the bootstrap. You want it to execute only when needed, not with every request.
As for the example you've provided, the correct version would be:
require_once "Zend/View/Interface.php";
class Zend_View_Helper_Foo extends Zend_View_Helper_Abstract {
}
The class that is extended by the helper is autoloaded and putting it in require_once does nothing.
public interface ReviewPanelStyle extends CssResource {...}
#Source("BlueReviewPanelStyle.css")
ReviewPanelStyle BlueReviewPanelStyle();
#Source("YellowReviewPanelStyle.css")
ReviewPanelStyle YellowReviewPanelStyle();
We would think that this should work, however it does not.
The color of elements styled (regardless of weather associated with the Yellow or Blue css) will be styled based on the order of these two lines.
Resources.INSTANCE.YellowReviewPanelStyle().ensureInjected();
Resources.INSTANCE.BlueReviewPanelStyle().ensureInjected();
As a work around I duplicated ReviewPanelStyle (ReviewPanelStyle2), but I rather not...any ideas?
Scoping of obfuscated class names is
defined by the return type of the
CssResource accessor method
Defining two separate interfaces for each style should do the trick. More information at http://code.google.com/webtoolkit/doc/latest/DevGuideClientBundle.html#Scope