What is the difference between Dynamic Component Loader and Lazy Loading? I need to build an application that needs to have an <router-outlet> at the root of the application. My Problem is that I don't know how to implement a Component that renders Child-Components according to data, dynamically. My current approach builds up on Dynamic Component Loader, but using this technique I have issues concerning tracking my location, navigate back, etc.
Is there any best practice for using "multiple <router-outlets>" (e.g. Lazy Loading)?
Thanks!
Loading components dynamically is not related to Lazy Loading.
Lazy Loading is a way to split up your application into modules that are loaded lazily (in the background) instead of loading your entire application at the start. This helps your app load more quickly so the first page is rendered sooner than it would if you did not use lazy loading.
For example, you might have a settings menu which loads various settings, but you don't expect users to visit that menu very often, so you put all the components for settings into a module and then you set that module to be loaded lazily (in other words none of that code needs to be downloaded unless a user actually visits the /settings route).
All angular applications must have a <router-outlet> at the base component (usually AppComponent). This is a requirement of all Angular applications.
You may want to consider also using auxiliary routes - these are optional, and allow you to load components in different 'places'. You can read about them here
Alternatively you can (for simple cases) just use ngIf, like this:
/app.component.html
<div *ngIf="isOption1(); else Option2">
<my-option1-component></my-option1-component>
</div>
<ng-template #Option2>
<my-option2-component></my-option2-component>
</ng-template>
/app.component.ts
public isOption1: boolean {
return <some test that returns true or false>;
}
So based on the logic the method isOption1 returns, the user will see either Option1 component (when true) or the Option2 component (when false).
Related
I know we should use unit tests for our reactjs components. But what I also want, is some way to manually test our components in isolation. Because we are working on small sprints in which we must deliver some finished component before having the page that first uses that component. And I want to see that full component really working (i.e. test integration with css and sub-components).
So to start with, I would like to see that new component rendered in black page that doesn't require that component directly, but to take that component name/path from a query-string parameter. And then I plan to add to that page some generic component configuration (e.g. a textbox with json representing the props to pass to that component).
The first problem I'm facing now is about how to configure webpack, webpack-dev-middleware, or webpack-dev-server to be able to load a component passed by parameter.
Anyone know how to that? Or a better way to handle this?
I would try something like this:
Set up an entry point that uses require.context.
Invoke require within that context based on your querystring. You should have you React component now. Render that through React.
In order to generate the test controls I would include the meta within the component using JSON Schema. The form controls could be then generated using some form generator such as plexus-form or tcomb-form.
I have some custom controls that I want to include in Xpages, but I don't want them to be visible to the user or to take up space on the screen, as it is throwing my alignment off. I have looked at the properties rendered, loaded, and visible, but I don't really understand them and they don't seem to do what I want, which is to include some functionality but not change the layout.
I am sure there is a way to do this, but I can't figure it out.
Loaded means it won't be added to the component tree and only affects server-side functionality. Because it's not in the component tree (the server-side map of the page) it can't be passed to the browser or processed during partial refreshes. Rendered and visible are the same and mean they're in the component tree, so server-side processing can interact with them, but no HTML is passed to the browser for them. So you can't interact with them via CSJS. If you want it passed to the browser, available for CSJS but not visible to the user, you'll need to set the style as display:none. Another option is to put that style in a theme and allocate the themeId you choose to your custom control.
I'm having a strange issue with Yii and a theme. I set it in config/main.php like:
'theme'=>'themeName',
as usual. But when I try to render a view, it is rendered as is, without any layout, as if I called:
$this->renderPartial
I double check that I don't call for renderPartial, the themes seem to be equal to all the others theme I've done. What can be this issue about?
Thank's for any help, I'm going out of mind on this...
Here is the structure and syntax that you should have to check
-yiiroot
-!-!protected
-!-!-!controllers
-!-!-!-!TestController.php
-!-!themes
-!-!-!themeName (it was the one that you have set on config file)
-!-!-!-!views
-!-!-!-!-!layouts
-!-!-!-!-!-!main.php // It would be default what if public $layout has not been overwriten or the layout file which has been set was not found
-!-!-!-!-!test
-!-!-!-!-!-!viewName.php
On controller TestController
public $layout is main as default or is overwritten there
in actionIndex you set $this->render('viewName');
If you rendered your page by method renderPartial() directly in controller, you would not get the layout template for sure
render() is commonly used to render a view that corresponds to what a
user sees as a "page" in your application. It first renders the view
you have specified and then renders the layout for the current
controller action (if applicable), placing the result of the first
render into the layout. It then performs output processing (which at
this time means automatically inserting any necessary tags
and updating dynamic content) and finally outputs the result.
renderPartial() is commonly used to render a "piece" of a page. The
main difference from render() is that this method does not place the
results of the render in a layout. By default it also does not perform
output processing, but you can override this behavior using the
$processOutput parameter.
renderFile() is a low-level method that does the grunt work of
rendering: it extracts the data variables in the current scope and
then runs the view code. The other two methods internally call this
one, but you should practically never need to call it yourself. If you
do, keep in mind that you need to pass in a file path (not a view
path).
Reference: Yii difference between rendering functions
I' working on a library control for Xpages and need some help in creating.
I would create a control which reads a configuration file and creates controls in a table, controls like Editboxes, checkboxgroups and so on.
so and now to my questions:
could I initiate controls from the Exlib or must I implement them all by my self?
if I could use them from the Exlib could anyone explain me how?
I hope its clear what i mean if not please ask me for further informations.
When creating your own components, if you're closely replicating some behavior that is already in an extension library component, I highly recommend you extend that component and just add what's needed to accommodate your different functionality. This makes things much easier and you don't have to code around every little scenario that the component might be placed in.
But, if you are developing a component that is nothing like any of the extension library or core components then just ensure your component extends UIComponent or UIComponentBase. If going this route, you'll also need to create your own renderer which extends Renderer. This is what will build the on-screen representation of your component. Again, if there's already something in the core components or extension library components that closely mimics what you need then make your renderer extend that renderer. Also, don't forget to include the renderer definition in the faces-config file and the component definition in the xsp-config file or your component won't work.
As for initiating controls from the extlib.... I assume you mean can you inject them onto the page at runtime. If so the answer is absolutely yes. To add an input text field to the page where there is a container (i.e. panel, div, span, whatever) with an ID of "someContainer"
XspInputText input = new XspInputText();
input.setValue("someValue");
input.setId("someID");
UIComponent container = FacesContext.getCurrentInstance().getViewRoot().findComponent("someContainer");
container.getChildren().add(input);
To see the api for all of the core and extension library components take a look at the XPages Controls Documentation. For a more complete tutorial on creating your own components take a look at my blog for creating a custom component inside an nsf, the steps are pretty much the same for putting them into a library:
Part 1,
Part 2 and there is an example database in the Part 2 post.
Is it possible to create a layout file inside of a module ? How ?
For what:
I want to add a some kind of statistics hit counter for products, and I don't want to override the products class, as that is already done by some module I'm using. Thus I thought it would be best to have a custom module with a block that would be called by a layout statement.
Of course I could easily edit my private local.xml or make changes to another layout-xml in the layout folder of my theme, but I want this feature to be available in all themes (independent of any selected theme).
Some constraints:
All code in one single module
... so that it is theme independent
... so that the module can be shared with others without them having to change anything (like theme files), so that the install/load of my module would be enough
I would also accept different approaches for my statistics hit counter loading (using the same constraints)
Yes it is possible. Just create your layout xml file in the following path: /design/frontend/default/default/layout/yourlayout.xml(or whatever your theme name is), and add a proper statement in your modules etc/config.xml:
<config>
<frontend>
<layout>
<updates>
<yourmoduleshortname>
<file>yourlayout.xml</file>
<yourmoduleshortname>
</updates>
</layout>
</frontend>
</config>
This sample is for frontend user, but adminhtml layouts can be updated in a similar manner. If something doesn't work, be sure to check if your layout is in the proper theme/package directory.
Edit:
Second approach:
You can use a controller of your own, which will extend the core functionality (one of the catalog controllers) - just rewrite it (or just product view action). Inside its action method add something like this:
$thiss->getLayout()->createBlock('namespacename/block','layout-block-name',
array('template' => 'relativepathtotemplate.phtml'));
$this->getLayout()->getBlock('content')->append($block);
run-original-parent-code();
Third approach:
Similar to the previous one, but you can use some event observer, and try Mage::getSingleton('core/layout'), and inject your block there. Not in all events the layout will be already available (try the post_dispatch family).
I don't really recommend the second and third approach, because if someone else wants to find where this 'magic' block comes from, it will most surely look int app/design/(...) directory. Finding it in your controller or model, may be very tricky...
If you don't want to display your statistic counter, you can also use events (like post_dispatch) to count the controller dispatches. Just create an observer attached to it, and store your data in the DB.