Re: [jira] [Commented] (TAP5-2169) Core stack is not included by default
jepp - that works.
but be aware - if you use the alerts component, the core stack will be
imported nevertheless: https://issues.apache.org/jira/browse/TAP5-2190
On Tue, Sep 24, 2013 at 2:17 AM, Bob Harner bobhar...@gmail.com wrote:
You mean just this?
public void
contributeMarkupRenderer(OrderedConfigurationMarkupRendererFilter
configuration) {
configuration.override(ImportCoreStack, null);
}
On Mon, Sep 23, 2013 at 12:49 PM, Howard Lewis Ship hls...@gmail.com
wrote:
Right on the money, but you can also override with null for the same
effect.
On Mon, Sep 23, 2013 at 2:38 AM, Felix Gonschorek fe...@netzgut.net
wrote:
intermediate solution. put this in your AppModule:
public void
contributeMarkupRenderer(OrderedConfigurationMarkupRendererFilter
configuration) {
MarkupRendererFilter NOOP = new MarkupRendererFilter() {
@Override
public void renderMarkup(MarkupWriter writer, MarkupRenderer renderer)
{
renderer.renderMarkup(writer);
}
};
configuration.override(ImportCoreStack, NOOP);
}
On Mon, Sep 23, 2013 at 11:29 AM, Felix Gonschorek fe...@netzgut.net
wrote:
Can we get a switch to turn off the auto-include of the core stack?
Please? ;-)
On Thu, Sep 19, 2013 at 2:58 AM, Barry Books trs...@gmail.com
wrote:
I agree with Geoff. It's easy to include the core stack in a Layout
component.
On Wed, Sep 18, 2013 at 7:48 PM, Lenny Primak
lpri...@hope.nyc.ny.us
wrote:
Technically I agree but it breaks compatibility. So I reluctantly
disagree.
On Sep 18, 2013, at 7:39 PM, Geoff Callender
geoff.callender.jumpst...@gmail.com wrote:
What changed? The JIRA issue says fixed but there's no info
about
how.
IMHO, it was a FABULOUS decision to emit minimal css classes and
NO
stylesheet. Developers are free to add the core stack if they
wish
and
free
to add refining css classes to the tml.
Who agrees/disagreees?
On 12 September 2013 11:57, Hudson (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/TAP5-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13765081#comment-13765081
]
Hudson commented on TAP5-2169:
--
SUCCESS: Integrated in tapestry-trunk-freestyle #1159 (See [
https://builds.apache.org/job/tapestry-trunk-freestyle/1159/])
TAP5-2169: Always import the core stack (hlship: rev
ec83d78d77c7dfde8688dd1f4db351414f42be7f)
* 54_RELEASE_NOTES.md
*
tapestry-core/src/main/java/org/apache/tapestry5/modules/TapestryModule.java
Core stack is not included by default
-
Key: TAP5-2169
URL:
https://issues.apache.org/jira/browse/TAP5-2169
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.4
Reporter: Lenny Primak
Assignee: Howard M. Lewis Ship
Priority: Minor
Fix For: 5.4
For simple applications, core stack is not included, which
breaks
the
UI,
because bootstrap.css and other assets are not loaded.
I think core stack should be forced to be included (possibly
optionally turned off by config)
but it should be included by default
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
Proposal for ObjectFactory service in 5.4
I created a pretty simple service that's proven quite useful. The interface
is
*public* *interface* ObjectFactory {
*public* T T build(ClassT clazz);
}
it's built on top of autobuild and since it's a service you can plug in
different factories. The one I have this
*public* *class* ObjectFactoryImplT *implements* ObjectFactory {
*private* *final* MapClass, Class config;
*private* *final* ObjectLocator locator;
*public* ObjectFactoryImpl(MapClass,Class config, ObjectLocator locator)
{
*this*.config = config;
*this*.locator = locator;
}
@SuppressWarnings({ unchecked, hiding })
@Override
*public* T T build(ClassT clazz) {
*if* ( config.containsKey(clazz) ) {
*return* (T) locator.autobuild(config.get(clazz));
}
*return* locator.autobuild(clazz);
}
}
This allows constructing real objects from interfaces with a config like
this:
@Contribute(ObjectFactory.*class*)
*public* *static* *void* contributeObjectFactory(MappedConfigurationClass,
Class configuration) {
configuration.add(PayLaterPayment.*class*, PayLaterPaymentDDB.*class*);
configuration.add(CreditCardPayment.*class*, CreditCardPaymentDDB.*class*);
configuration.add(PayPalPayment.*class*,PayPalPaymentDDB.*class*);
configuration.add(Invoice.*class*,InvoiceDDB.*class*);
configuration.add(InvoiceItem.*class*,LineItem.*class*);
}
What makes this useful is you can build modules that define interfaces and
then do things like
*public* *class* PayPalButton {
@Parameter
*private* PaymentMethod payment;
@Inject
*private* ObjectFactory objectFactory;
*void* onSelectedFromPayPal() { payment = objectFactory
.build(PayPalPayment.*class*); }
}
I also think it would make BeanEditForm even more useful. If there any
interest I'll open a JIRA and add the code.
Thanks
Barry
Re: Proposal for ObjectFactory service in 5.4
I don't think so. In my case the value passed to the build method is always
type Class and the return is a new object based on the class type.
The strategy builder service takes a set of services and constructs a new
service that directs calls by the object type of the parameters. You can't
use it for this purpose because in this case the parameter type is always
the same i.e. Class
On Fri, Sep 27, 2013 at 2:21 PM, Thiago H de Paula Figueiredo
thiag...@gmail.com wrote:
Is it just me or what you're proposing is very similar to what
StrategyBuilder.build(Class, Map) already does in the sense that you want
to associate certain objets to a given class (the config field in
ObjectFactoryImpl)?
On Fri, 27 Sep 2013 15:32:00 -0300, Barry Books trs...@gmail.com wrote:
I created a pretty simple service that's proven quite useful. The
interface
is
*public* *interface* ObjectFactory {
*public* T T build(ClassT clazz);
}
it's built on top of autobuild and since it's a service you can plug in
different factories. The one I have this
*public* *class* ObjectFactoryImplT *implements* ObjectFactory {
*private* *final* MapClass, Class config;
*private* *final* ObjectLocator locator;
*public* ObjectFactoryImpl(MapClass,**Class config, ObjectLocator
locator)
{
*this*.config = config;
*this*.locator = locator;
}
@SuppressWarnings({ unchecked, hiding })
@Override
*public* T T build(ClassT clazz) {
*if* ( config.containsKey(clazz) ) {
*return* (T) locator.autobuild(config.get(**clazz));
}
*return* locator.autobuild(clazz);
}
}
This allows constructing real objects from interfaces with a config like
this:
@Contribute(ObjectFactory.***class*)
*public* *static* *void* contributeObjectFactory(**
MappedConfigurationClass,
Class configuration) {
configuration.add(**PayLaterPayment.*class*, PayLaterPaymentDDB.*class*);
configuration.add(**CreditCardPayment.*class*,
CreditCardPaymentDDB.*class*);
configuration.add(**PayPalPayment.*class*,**PayPalPaymentDDB.*class*);
configuration.add(Invoice.***class*,InvoiceDDB.*class*);
configuration.add(InvoiceItem.***class*,LineItem.*class*);
}
What makes this useful is you can build modules that define interfaces and
then do things like
*public* *class* PayPalButton {
@Parameter
*private* PaymentMethod payment;
@Inject
*private* ObjectFactory objectFactory;
*void* onSelectedFromPayPal() { payment = objectFactory
.build(PayPalPayment.*class*); }
}
I also think it would make BeanEditForm even more useful. If there any
interest I'll open a JIRA and add the code.
Thanks
Barry
--
Thiago H. de Paula Figueiredo
--**--**-
To unsubscribe, e-mail:
dev-unsubscribe@tapestry.**apache.orgdev-unsubscr...@tapestry.apache.org
For additional commands, e-mail: dev-h...@tapestry.apache.org
Re: Proposal for ObjectFactory service in 5.4
On Fri, 27 Sep 2013 16:39:14 -0300, Barry Books trs...@gmail.com wrote: I don't think so. In my case the value passed to the build method is always type Class and the return is a new object based on the class type. In StrategyBuilder/StrategyRegistry's case, the parameter is always Class. You could implement your proposed service using StrategyBuilder, which just doesn't do the service instantiation you want. As an example, you can look at TapestryModule.constructComponentEventResultProcessor(). What's the use case? Having entity classes injected with services? Just curious. :) The strategy builder service takes a set of services and constructs a new service that directs calls by the object type of the parameters. You can't use it for this purpose because in this case the parameter type is always the same i.e. Class In the StrategyBuilder case, the key is always a Class instance: the registered Map is Class, T, where T is any type you want, but the key is always Class. -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
lezon commented on http://tapestry.apache.org/index.html
Hello, lezon has commented on http://tapestry.apache.org/index.html. You can find the comment here: http://tapestry.apache.org/index.html#comment_1745 Please note that if the comment contains a hyperlink, it must be approved before it is shown on the site. Below is the reply that was posted: im all time so feeling..hot..if get a work with pprn midia..may be i can do the modeler is so perfect action.if get any horny..is wanna need a 26years oldet younger hardly boy..pls contect with my phone number..0060176801137 With regards, The Apache Tapestry Project. You are receiving this email because you have subscribed to changes for the tapestry site. To stop receiving these emails, unsubscribe from the mailing list that is providing these notifications. - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
[T5.4-a-22] Core stack being added to page non-HTML MarkupWriter-generated output
Hi! I'm writing a page to generate an RSS 2.0 document though MarkupWriter[1]. Tapestry is then trying to add JavaScript to it anyway: The root element of the rendered document was rss, not html. A root element of html is needed when linking JavaScript and stylesheet resources. Is this a bug? I think so, even being something of a corner case. Shouldn't Tapestry refrain from adding the core stack (or any CSS or JavaScript) for pages with content type different than text/html or application/xhtml+xml (XHTML)? [1] I do that to avoid needing to use some XML DOM implementation and then serialize it as a String to return a StreamResponse. Also to avoid an external dependency to an RSS package like Rome. -- Thiago H. de Paula Figueiredo - To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
