According to http://www.gebish.org/manual/current/modules.html#modules
Modules should be defined like this:
class ExamplePage extends Page {
static content = {
theModule { module ExampleModule }
}
}
From Geb's Documentation:
16.2.2 Strong typing
In order to gain improved authoring support, you must include types in
your tests and page objects. Additionally, you must explicitly access
the browser and page objects instead of relying on dynamic dispatch.
So:
HomePage homePage = browser.to HomePage
homePage.loginButton.click()
It's works fine for Pages, but can i find the way to have it with Modules aswell?
to have autocompletion here:
HomePage homePage = browser.to HomePage
homePage.loginFormModule. *autosuggestion here*
(where "loginFormModule" - is module of HomePage)
Stronger typing for module definitions has been recently added to master but hasn't been released yet. Basically the location of module() method has changed so that now IntelliJ understands the return type of it. If you wish to give it a try then you can use 0.10.1-SNAPSHOT from Geb's snapshot repo. The way you pass a base navigator and parameters to a module has changed, see the latest chapter on modules for info. It would be awesome if you could give it a try and tell me if by simply changing the version you get autocompletion.
Related
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
I would like to have a semantic named custom element that extends from button: like fab-button
class FabButton extends HTMLButtonElement {
constructor() {
super();
this.html = hyperHTML.bind(this);
}
}
customElements.define("fab-button", FabButton);
Extending for HTMLButtonElement doesn't seem to work.
Is there a way to extend from a non-HTMLElement with the HyperHTML "document-register-element.js"?
Codepen example:
https://codepen.io/jovdb/pen/qoRare
It's difficult to answer this, because it's tough to understand where to start from.
The TL;DR solution though, is here, but it needs a lot of explanations.
Extending built-ins is a ghost in the Web specs
It doesn't matter what WHATWG says, built-ins are a de-facto death specification because Webkit strongly opposed to it and Firefox, as well as Edge, that never even shipped Custom Elements, didn't push to have them neither.
Accordingly, as starting point, it's discouraged to extend built-ins with Custom Elements V1 specification.
You might have luck with V0 though, but that's only Chrome API and it's already one of those APIs created to die (R.I.P. WebSQL).
My polyfill follows specs by definition
The document-register-element polyfill, born with V0 but revamped with V1, follows specifications as close as possible, which is why it makes extending built-ins possible, because WHATWG still has that part in.
That also means you need to understand how extending built-ins works.
It is not by defining a simple class that extends HTMLButtonElement that you get a button, you need to do at least three extra things:
// define via the whole signature
customElements.define(
"fab-button",
FabButton,
{extends: 'button'}
);
... but also ... allow the polyfill to work
// constructor might receive an instance
// and such instance is the upgraded one
constructor(...args) {
const self = super(...args);
self.html = hyperHTML.bind(self);
return self;
}
and most important, its most basic representation on the page would be like this
<button is="fab-button">+</button>
Bear in mind, with ES6 classes super(...args) would always return the current context. It's there to grant super constructors didn't return other instances as upgraded objects.
The constructor is not your friend
As harsh as it sounds, Custom Elements constructors work only with Shadow DOM and addEventListener, but nothing else, really.
When an element is created is not necessarily upgraded yet. in fact, it won't be, most likely, upgraded.
There are at least 2 bugs filed to every browser and 3 inconsistent behaviors about Custom Elements initialization, but your best bet is that once connectedCallback is invoked, you really have the custom element node content.
connectedCallback() {
this.slots = [...this.childNodes];
this.render();
}
In that way you are sure you actually render the component once live on the DOM, and not when there is not even a content.
I hope I've answered your question in a way that also warns you to go away from custom elements built-ins if that's the beginning of a new project: they are unfortunately not a safe bet for the future of your application.
Best Regards.
1.what we are planning to do :
Reuse the ManifestEditor to open the MANIFEST.MF file, and add our features to the first OverviewPage.
2.what we already have known and done :
It's dangerous to use the internal classes and APIs, so we create a ManifestEditorNew which extends ManifestEditor.
import org.eclipse.pde.internal.ui.editor.plugin.ManifestEditor;
import org.eclipse.pde.internal.ui.editor.plugin.OverviewPage;
public class TheNewManifestEditor extends ManifestEditor{
//it's strange that the default fist page is not the OverviewPage,so we override this method
#Override
protected String computeInitialPageId() {
return OverviewPage.PAGE_ID;
}
}
3.what Exception we meet :
The NullPointerException.
Once our TheNewManifestEditor gained focus, the give us an NPE, but we can not find ant clues which caused this.
You probably need to called super.computeInitialPageId() because it looks like it does some set up.
Note: The reason the overview page is not always shown is because the editor remembers the the last page you looked at and shows you that. It will default to the overview page the first time the manifest is edited.
Just extending an internal class does not remove the fact that you are using internal Eclipse classes which violates the Eclipse API Rules of Engagement. Internal classes can and do change and sometimes even disappear altogether, you are likely to have a lot of trouble when moving between Eclipse releases.
I just started using Lift's Wizard/LiftScreen classes and need to add placeholder text to my text fields. I found the FieldTransform class as a solution to this here
https://groups.google.com/forum/#!topic/liftweb/x_t9rvvZ8jk and here http://comments.gmane.org/gmane.comp.web.lift/59985
But now I'm trying to use that information, but can't for the life of me figure out what import statement is needed (where the class is, in the libraries).
Lift 2.5-M3 talks about the API changing liftweb.net/25_m3, but nowhere do I find the class actually listed in the API (liftweb.net/api/25/api/#package).
What's the import I need? How should I be looking this up; I'd like to know how to find a class quickly next time.
EDIT:
To be a good Stackoverflow citizen, here's some code.. :-)
object WizardExample extends Wizard {
val screen1BrandInfo = new Screen {
val brandName = field("Name", "Mike")
}
}
I'm trying to add HTML5 placeholder text to the "Name" field so the user sees sample text when they view the page.
RESOLUTION:
Wow, that was my first StackOverflow. I'm blown away by what I've learned from you guys in a few hours!
#jcern: thanks for all your help. I'm working in Lift 2.4, so initially I didn't find FieldTransform in Wizard$Screen, then I clicked on the link you provided (2.5) and saw it. What a jungle to navigate! Thanks for all your help. I now see how to navigate all this. And thanks again so much for the "All" view hint. That was critical!
#Vasya Novikov: Thanks so much for this answer. This is what I'll have to do since I'm working in 2.4 and don't have access to FieldTransform.
The two best places to find classes in Lift are either in the API:
http://liftweb.net/api/25/api/#package
Or, directly in GitHub (where you can search for classes and for text/definitions within them):
https://github.com/lift/framework
As for the FieldTransform class, that should be available to any class that extends LiftScreen. See the API here -- you may need to toggle the visibility to All to see FieldTransform as it is a protected class.
You can import LiftScreen with:
import net.liftweb.http.LiftScreen
I'm creating a plugin for my symfony project, which includes a base action class, i.e.:
<?php
// myActions.class.php
class myActions extends sfActions {
/* ... */
}
Where in my plugin folder (e.g.: plugins/sfMyPlugin/???) should I place this file?
The goal is to have actions that are NOT a part of this plugin extend this class, hopefully having the class be autoloaded (similar to if it were placed under apps/my_app/lib). If it can't be autoloaded, how do I get symfony to include my php file?
You typically put it in your plugin's lib directory. The general conventions is also to to name with Base in the name so given your example that would be BasemyActions. Then you would also make an empty concrete class called myActions and you would extend that within your plugin thus allowing other user to complety replace myActions with their own implementation (so long as it extends the base class) or to simply extend myActions.
you can place it in the lib directory of your plugin. This is what the generate:plugin-module task of the sfTaskExtraPlugin does.