All
I have seen the jboss-service.xml which use an extended SystemPropertiesService class to reference to custom property file. But I didn't totally understood this kind of usage yet.
Could someone please give me some help to understand how to use these two class? thanks.
The SystemPropertiesService is very useful to define properties that then can be accessed from your application, it's usually used to parametrize the application without having to change to code, or even the application package (provided you place the jboss-service.xml outside de war / ear / jar structure). For example, you can create a myapp-service.xml file with the following content:
<server>
<mbean code="org.jboss.varia.property.SystemPropertiesService" name="jboss:type=Service,name=MyAppProperties">
<!-- Define the properties directly in the service.xml file-->
<attribute name="Properties">
myapp.property1=property1Value
myapp.property2=property2Value
</attribute>
<!-- You can also specify a route to another file where you define properties-->
<attribute name="URLList">
/home/myuser/txtlist.properties
</attribute>
</mbean>
</server>
Then you can deploy this file directly in JBoss, the properties defined will be visible to all the applications deployed in the same JBoss and you'll be able to access them with the static method:
String System.getProperty(String propertyName)
So if you want to access to the value of myapp.property1 from your application you'd do:
String property = System.getProperty("myapp.property");
On the other hand the PropertyListener is really an interface that defines a listener that will be triggered when any event occurs with a property. The org.jboss.util.property.PropertyAdapter is an abstract implementation of this interface. To use it you've to implement its three methods (propertyAdded, propertyChanged, propertyRemoved), that will be called by the container when a property is added, changed or removed respectively. Those methods have a PropertyEvent object as parameter, which let you know the property affected.
This interface/class is useful when you want your application to do something every time a property changes (a bad implementation would be that you check every certain time for a property change), this way, when JBoss detects that a property has changed its value, it will call the respective method (that you should implement with the behaviour you want).
For example, if you want to print the new property value everytime it's changed you could implement the propertyChanged method this way:
void propertyChanged (PropertyEvent pe){
// check the property that has changed
if (pe.getPropertyName().equals("myapp.property1")){
System.out.println("The value of " + pe.getPropertyName() + " has changed to " + pe.getPropertyValue());
}
}
Look for more information in the API, and for PropertyAdapter and PropertyEvent.
In JBOSS 5.1 it only works when you put the properties or URL in properties-service.xml and this file should go under jboss.home/server/default/deploy directory.
Related
Setting the scene:
I'm working on a webapp in Eclipse, with a bunch of JSPs and XSLs. And I need to hide some features depending on some users' attributes. This is the third job in the series.
For the previous 2 jobs, I was able to achieve my goals because either the required changes were on JSPs (straightforward) or on XSLs for which the objects existed.
I.e. We have the following sequence:
- searchForm.jsp (a form with some criteria you set up and submit),
- resultsList.jsp (a list of search results - clicking on any result brings the full record for the result),
- displayItem.jsp (the full record),
- record.xsl (the xsl that transforms displayItem.jsp).
Thus for the 2 previous jobs, the features I needed to hide were either on these JSPs themselves or on the xsl, in which case the (relevant) JSPs had:
<c:set target="${item}" property="xsltParameter" value="xxxx=Y"/>
where 'item' is an existing object and 'xxxx' a (usually but not necessarily global) parameter defined in the xsl.
For example:
<xsl:param name="xxxx">N</xsl:param>
Thus, if my changes were on the xsl, I would reuse the 'item' object to pass on my parameter and process it in the XSL(s).
E.g. I'd put on the jsp:
<c:set target="${item}" property="xsltParameter" value="abcd=AAA"/>
and add to the xsl:
<xsl:param name="abcd"></xsl:param>
This way I was able to pass my own parameters to the xsl.
For this last job however:
- The XSL (filters.xsl) is quite short and self-contained.
- It appears on the same page as resultsList.jsp, (therefore after searchForm.jsp) but has no connection I can see with it.
- On the JSPs, there's NO (appropriate) target object I can (re)use.
- I've already tried on a/the JSP the way I know to create variables/parameters:
<c:set var="xyz" value="${abcd}"/>
but this doesn't seem to work (when I create a corresponding xyz global parameter in filters.xsl).
My issues are:
- I'm struggling to create an object (if that's what I need to do).
- I may need to do something else, but I'm not sure what (hence my post).
Plan B
In desperation, with plan B I'm creating as a proof-of-concept, a static xml file (param-val.xml), in the same location as the XSLs, in which I put my external parameter/criterion:
<paramroot>
<paramval>abcd</paramval>
</paramroot>
What I'd like to do is using the document() function, extract this parameter and use it either within filters.xsl if possible or otherwise a go-between prefilters.xsl that filters.xsl would import. And this is where I'd need some help/tips/etc.
<xsl:param name="theXML" select="'prefilters.xml'" />
<xsl:variable name="myDoc" select="document($theXML)" />
I've been reading stuff on the web and tested a few things, but I'm stuck (rusty on some topics and learning others). How can I grab and use the 'abcd' in either filters or prefilters?
Any suggestions on how best to handle this?
Sorry for the lenghty post. Any help would be greatly appreciated.
Many thanks and regards.
I'm new to JBPM and am trying to wrap my head around a new project, and recently noticed that while trying to define some user task forms I couldn't find a form option for a drop-down list
At this point my knowledge of the technology is pretty small, and this seems like a strange limitation at first glance, which should have an easy work-around, but I'm having difficulty finding a quick and dirty solution.
Is this something I'd have to code in Eclipse, or something else?
The answer that #cego provides is correct for "hard-coded" values, if you want to load dynamic values (from a database for example) you can use the Select Box field type and configure it to use a SelectValuesProvider that calculates the combo values.
To create a SelectValuesProvider you should create a java project with a mvn dependency to:
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-form-modeler-api</artifactId>
</dependency>
Once you did that you can create your class that implements org.jbpm.formModeler.core.config.SelectValuesProvider. This interface provides two methods:
String getIdentifier(): should return a unique String that identifies this provider. This String will be shown on the Select Box configuration popup.
Map getSelectOptions(Field field, String value, FormRenderContext renderContext, Locale locale): This method have to return a Map containting the key, text that are going to be load on the Select box. The received parameters are:
Field field: the configuration of the field that is going to be evaluated.
String Value: the current value of the field
FormRenderContext renderContext: a class that contains all the information about the form that is rendered at that moment.
Locale locale: the locale in which is being rendered the form.
Once you've created this provider, you must compile your project and put the jar on the server classpath and restart it. After doing that you'll be able to create a form (or edit an existing one), add a Select Box field and choose your provider on the "Data provider" combo box.
Hope it helps, if you have any doubt please ask and I'll try to create an example.
Regards,
Pere
Ok, for old versions you can do it turning a textbox to a combobox using a RangeProvider. This is a very similar solution to the previous one.
First you should create java project with a mvn dependency to:
<dependency>
<groupId>org.jbpm</groupId>
<artifactId>jbpm-form-modeler-api</artifactId>
</dependency>
After that you have to create your RangeProvider class that implements org.jbpm.formModeler.api.model.RangeProvider and implement it's methods. As the SelectValuesProvider on the previous example this interface provides two methods:
- String getType(): A unique String to identify the provider
- Map getRangesMap(String namespace): This method have to return a Map containting the key, text that are going to be load on the combo box. It only receives a String parameter, it is an identifier that allows you to get all the information about the form that is being rendered.
Also you have to create a META-INF/beans.xml file to allow to lookup your provider via CDI (I missed this step on the previous example, sorry).
As the previous example, once you've created the provider you must compile your project and put the jar on the server classpath and restart it.
When the server is started you have to create a new form (or open an existing one), add a TextBox field, edit it's properties and write the string returned by your RangeProvider's getType method on the "Range value" property.
Save the field properties and if everything is fine the field would be rendered as a combobox showing the values returned by your provider.
To create a select element(drop-down list) look for "Setting a Range Formula" in this part of the documentation: http://docs.jboss.org/jbpm/v6.1/userguide/chap-formmodeler.html#sect-formmodeler-FormulasExpression
I know this has been asked before, but I seem to be going around in circles
Where in the magento file structure is the HTML file that displays amongst other things Anashrias Sandals(as well as Magentos end of summer sale etc...)
Ive installed the sample application to Magento CE V1.7.0.2
I can see the definition in Magento/Admin under CMS->Pages->Home Page->2 Columns with Left Bar, but Ive wondered all through the file system. The PHTML specifies the familiar
echo $this->getChildHtml('content')
But I cant seem to find anything that 'content' could resolve to that display Anashrias graceful feet and sandals
Content.phtml simply states
getPageContent(); ?>
Arghhhhhhh
Even turning debugging on puts dashed red lines around every block EXCEPT the content page
Sadly those wonderfully manicured toes must go
...but how
I was going to just comment, but to explain thoroughly I need more space ;)
To answer your comment directly, the content you see isn't necessarily in a file somewhere, the "content" for CMS pages are within your database. By changing the content field on your CMS Page (Magento Admin -> CMS -> Pages -> select a page from the list), you can change the center content for that page. Magento has many different page "types" (Each Parent of the tags in xml (explained later) is a layout handle signifying a page type), common examples are cms, category, product, checkout, cart, customer account, etc.
So, when you see $this->getChildHtml('content');, what you see is a call to the system to pull the child block named "content" from the XML. This changes depending on what page you are on, as dictated by the XML and Magento Core Code.
Layout Files
Lets take a look at the source of where the name "content" comes from. Our current working directory is /app/design/frontend/base/default/layout/. In this folder you will see a list of .xml files, these are the files that dictate how a page is put together. The block named "content" is originally defined in page.xml at around line 91:
<block type="core/text_list" name="content" as="content" translate="label">
<label>Main Content Area</label>
</block>
Also, note that this section is "nested" in the <default></default> tags. Those tags are the layout handles I was talking about, and this shows that all pages should be loaded with this xml layout by default. So here is our "content" block, in all its glory. It's actually just a namespace. The other layout pages will each load what they need from within the content block.
Now, let's look at another relevant layout file, cms.xml, around line 45:
<cms_page translate="label">
<label>CMS Pages (All)</label>
<reference name="content">
<block type="core/template" name="page_content_heading" template="cms/content_heading.phtml"/>
<block type="page/html_wrapper" name="cms.wrapper" translate="label">
<label>CMS Content Wrapper</label>
<action method="setElementClass"><value>std</value></action>
<block type="cms/page" name="cms_page"/>
</block>
</reference>
</cms_page>
Here, the <reference name="content"> denotes that everything nested here is a child of the "content" block. We don't need to call it like <block name="content"/> because we know it was already defined in page.xml.
From there, they have the "cms.wrapper" block, which basically just sets the div that "wraps" around the rest of the cms content. Nested within the wrapper is our <block type="cms/page" name="cms_page"/>. This is the bad boy that outsources our template job to the cms/page block class, located in app/code/core/Mage/cms/page.php. From there, basically the class will grab our CMS Page detail from the database and present it for all to see.
So, to answer your question in short, there is no file that has the content of the cms pages, it is pulled from the database and generated upon page request.
Block Tag Explained
Blocks have various attributes to it, I'll go over the basics.
type="core/template": The type denotes what kind of block class it is. This refers to the folders nested in the "app/code/core/Mage/" folder (typically, with exceptions*). Here we are referring to app/code/core/Mage/Core/Block/Template.php. The class you set here will be attached to your template. This is responsible for the prolific use of $this->doSomething() in your template files. Basically the template file is calling the class object to do the work. "core/template" is a good general use class to fall back on when adding custom template files, although in certain circumstances you may need to choose something else.
name="content": Here we are giving our block a name. It would be the identifying name of the block, and it's used to reference that block everywhere. The block name is needed for such things as xml references (<reference name="blockName">) and to call blocks from within parent phtml template files (<?php echo $this->getChildHtml('blockName'); ?>). Note that all templates which call it without an argument ($this->getChildHtml('');) means to call ALL child blocks without being explicitly called.
as="content": This signifies an alias identifier. You can use the alias the same as the name above.
template="page/html/callouts.phtml": This sets the template for the block. Magento will look for app/design/frontend/your_package/your_theme/template/page/html/callouts.phtml and use it as the block's layout.
*Exceptions: Third-party extensions typically use either app/code/community or app/code/local folders. If you have to overwrite a core class, copy the directory structure to the local folder and then make your edits to the local version of the class.The classes load in this order: /local/ > /community/ > /core/. If a local version is found it will use that first, followed by community and core, and takes the first class file found with that name.
local.xml
Let me introduce you to the proper way of modifying your layout. Here, create a file called local.xml in your directory app/design/frontend/your_package/your_theme/layout/. This one file will house all your layout updates, to prevent any conflicts that may arise if you start editing the base layouts. Also, it keeps all your custom changes in one tidy file.
We'll remove some things that the demo store puts in that isn't really needed. Your layout should look like this, to start:
<?xml version="1.0"?>
<layout version="0.1.0">
<!-- Layout Handle -->
<default>
<!-- Block Reference -->
<reference name="left">
<!-- Remove by Reference Name -->
<remove name="left.permanent.callout"/>
</reference>
<reference name="right">
<remove name="right.permanent.callout"/>
</reference>
</default>
</layout>
Not a whole lot there, but what this will do is remove the callout ads on the left and right side bars. You'll need to refresh your cache upon making layout xml changes.
Read another one of my answers for some more things you can do with local.xml:
Magento Sidebar Customization
Edit 08/16/13:
I glossed over the Magento Design Guide (I had it once, good resource to start off, but by the first time I read it I already had learned everything it had to offer). The fallback structure it speaks of is in regarding the code/template/layout/skin/translation files.
The packages to use are partially set by you, in System->Configuration->Design. If it is not found, then it falls back to default. If default doesn't have what it's looking for, it grabs the base file. Magento does this inherently by design.
Unfortunately I don't see any built in mechanism for falling back database content. The cms content is made up of 4 tables, cms_block, cms_block_store, cms_page and cms_page_store. cms_block_store and cms_page_store each only contain the page/block id and the store id. both ids are primary keys. This is to relate the page/block id to which store it belongs to.
I suppose you could try to instigate a fallback for cms content by having it search for that page with store id, and if not, fall back to the same page ID from a different store. Or perhaps make a "base" store record that is only used as the fallback store id. I wouldn't be sure exactly how to implement either one though.
For your reference these are the cms_block and cms_page tables:
cms_block Table
[block_id] //Internal Id, Auto Increments and is Primary Key
[title] //Block Title as User Defined
[identifier] //Block Identifier, also User Defined
[content] //Block Content Stored Here
[creation_time] //Date-Time the Block was Created (ex. 2013-07-22 17:21:18)
[update_time] //Date-Time the Block was Last Updated
[is_active] //Show(1) or Hide(0) Block.
cms_page Table
[page_id] //Internal Id, Auto Increment, Primary Key
[title] //Page Title
[root_template] //Template Layout (one_column, two_columns_left, etc)
[meta_keywords] //Meta Keywords
[meta_description] //Meta Description
[identifier] //User Defined Page Identifier
[content_heading] //Content Heading to be Displayed
[content] //Page Content
[creation_time] //Date-Time Page Created
[update_time] //Date-Time Page Last Updated
[is_active] //Show(1) or Hide(0) Page (0 = 404 error)
[sort_order] //Legacy(?) Page Sorting Order**
[layout_update_xml] //XML Layout Changes***
[custom_theme] //Override Page w/ Different Theme
[custom_root_template] //Override Page w/ Different Layout than Set Above
[custom_layout_update_xml] //Override Page Layout w/ Different XML***
[custom_theme_from] //Set Date to Start Overriding Page w/ Custom Layout
[custom_theme_to] //Set Date to End Overriding Page w/ Custom Layout
/*
/**I don't see anywhere to set via Admin Back-End. All mine are set to (0),
/ my best guess is it was used to sort page link order in a menu. Either
/ they removed this feature somewhere along the way or I somehow removed
/ it and forgot.
/
/***Think local.xml without the need to use the layout handle. In other words:
/ You can modify specific pages with the same xml styling as used between
/ the <default></default> tags above. Don't actually put <?xml>, <layout>
/ or <default> (the update handle) tags.
*/
So that's all that is in the cms portion of the database.
Fallback
When properly configured, Magento will fall back in this order:
<!-- Front End Package/Theme Template and Layout Files -->
app/design/frontend/yourPackage/yourTheme/
app/design/frontend/yourPackage/default/
app/design/frontend/default/default/
app/design/frontend/base/default/
<!-- Admin Package/Theme Template and Layout Files -->
app/design/adminhtml/yourPackage/yourTheme/
app/design/adminhtml/yourPackage/default/
app/design/adminhtml/default/default/
<!-- Front End Package/Theme Skin (JS/CSS/Images) Files -->
skin/frontend/yourPackage/yourTheme/
skin/frontend/yourPackage/default/
skin/frontend/default/default/
skin/frontend/base/default/
<!-- Admin Package/Theme Skin (JS/CSS/Images) Files -->
skin/adminhtml/yourPackage/yourTheme/
skin/adminhtml/yourPackage/default/
skin/adminhtml/default/default/
<!-- Magento Code Pool -->
app/code/local/**
app/code/community/***
app/code/core/
/*
/**Magento will, by default, only look within local folders that currently
/ exist in the core directory, community directory*** OR if an active
/ module has codePool*** set to local.
/
/***Third-Party modules have to set which codePool they are using, which
/ specifies the default working directory for that module's code.
/ This is defined in the xml located at /app/etc/modules/*. If a module
/ has its codepool set to community, you can override the extension's
/ code by copying it to local.
/*
The "community" codePool is said to be there for legacy reasons, and that new extensions should be made to use the "local" only. I personally don't agree, it would make much more sense for every Third-Party extension to use the community codePool and retain the ability to override the original extension code from "local" without modifying the original.
Okay, I think I'm done with this question, as any more information here would be overload. If I missed anything, start a new question and link me to it ;D.
I'm trying to replicate the loading of a property file of seam in javaee6 but still don't know where to start.
In seam we can load a property file as a seam component by defining it in the components.xml:
<component name="propertyBean" class="PropertyBean" scope="application" auto-create="true" startup="true">
<property name="filename">myPropertyFile.properties</property>
<property name="reload">true</property>
</component>
And then we can access it in code:
PropertyBean.getInstance().getProperty("myProperty");
Is there a javaee6 feature that will replicate this functionality? Or in spring it's called PropertyPlaceholder.
In c#, we can do it by adding configuration property in appsettings.xml. And access via ConfigurationManager.
Thanks,
czetsuya
Unfortunately, there's nothing like a property component manager from seam into javaee6, but I was able to find something similar, a property loader.
It works by having a qualifier:
#Qualifier
#Retention(RUNTIME)
#Target({METHOD, FIELD, PARAMETER, TYPE})
public #interface ConfiguredBy {
#Nonbinding public String value();
}
With a parameter that serves as the name of the property file.
The whole approach is describe here:
http://john-ament.blogspot.com/2010/03/writing-property-loader-in-java-ee-6.html
How to debug EL in the JSF page? I'd like to watch variable values, function calls an so on. The best solution would be an eclipse plugin, but any other possibility is better than guessing "Why this expression failed to render correctly?".
Closest what you can get in JSF/Facelets is placing an <ui:debug /> somewhere in the view:
<ui:debug />
Pressing CtrlShiftD should then show a popup window with debug information about the component tree and all available request parameters and request/view/flash/session/application scoped variables. It's basically a representation of the content of all those maps.
The hotkey is by the way configureable by hotkey attribute so that you can choose another whenever it clashes with browser default hotkeys, as it would do in Firefox; CtrlShiftD would by default show the Add bookmarks dialogue. Here's how you could make it to listen on CtrlShiftX instead:
<ui:debug hotkey="x" />
You'd usually also like to hide it in non-development stage, so add a rendered condition like that:
<ui:debug hotkey="x" rendered="#{facesContext.application.projectStage == 'Development'}" />
In the shown debug information, the information provided about scoped variables isn't that great as you would expect. It only shows the Object#toString() outcome of all scoped variables which defaults to com.example.Bean#hashcode. You can't explore their properties and the values of their properties directly like as you could do in debug view of Eclipse's debugger. You'd need to implement toString() on the class accordingly so that as much as possible relevant information is returned (if necessary, you can even let Eclipse autogenerate it by rightclick source code > Source > Generate toString()):
#Override
public String toString() {
return String.format("Bean[prop1=%s,prop2=%s,prop3=%s]", prop1, prop2, prop3);
}
As to method calls, just put a breakpoint on the Java source code the usual way. Eclipse will kick in there as well when EL calls the method. If it's a managed bean, you'll also just see its properties in the Eclipse debugger.
If you are really having problems then if you can get the source for the EL implementation (easy enough for the RI) then you can use Eclipse to set breakpoints in the EL implementation methods. You need to get an understanding of how the EL code works, but it isn't that complicated. Not for the very faint hearted though.
Another possibility would be to create and evaluate the EL programatically. There are examples of how to do this around. You can then use the debugger to fiddle around with what the expression is and what the result is until you've worked out where your problem lies.