On Thu, Oct 25, 2012 at 4:39 AM, Denis Stepanov
<[email protected]> wrote:
> I'm looking into current changes and I have few suggestions.
>
> Some time ago I have rewritten the javascript part of Tapestry using
> CoffeScript and pure jQuery, I would like to use it in the future with
> minimal changes, to do so there should be an abstract layer between core
> components and client logic.
>
> Right now ProgressiveDisplay has this code:
>
> jsSupport.require("core/zone").invoke("deferredZoneUpdate").with(clientId,
> link.toURI());
>
> it is very implementation specific, I would suggest to create a service
> similiar to the ClientBehaviorSupport. ProgressiveDisplay will call
> addProgressiveDisplay(Element element, String clientId, Link link) first
> parameter should be always element to allow additional configuration. Client
> side service implementaton could be easily replaced or extended.
See notes before; the last thing I want to do is add yet more layers
of abstraction! ClientBehaviorSupport was a mistake from the start.
If you don't want something that works like ProgressiveDisplay, write
your own. What's nice now is just how minimal it is; there's almost
nothing left!
>
> Also Zone component:
>
>
> Element e = writer.element(elementName,
> "id", clientId,
> "data-container-type", "zone");
>
> if (insideForm)
> {
> JSONObject parameters = new
> JSONObject(RequestConstants.FORM_CLIENTID_PARAMETER,
> formSupport.getClientId(),
> RequestConstants.FORM_COMPONENTID_PARAMETER,
> formSupport.getFormComponentId());
>
> e.attribute("data-zone-parameters",
> parameters.toString(compactJSON));
> }
>
> should be:
>
> Element e = writer.element(elementName, "id", clientId);
>
> clientSupport.addZone(e);
>
> if (insideForm) {
> clientSupport.addZoneInsideFormParameters(e,
> formSupport.getClientId(), formSupport.getFormComponentId());
> }
Actually, your clientSupport object should be able to determine if
there is a FormSupport environmental, and add the necessary data-
attributes.
>
If you check what I've written, I've been trying to avoid these extra
abstraction layers! What I'd rather do is better document what the
various AMD modules do in terms of document event handlers, and what
special data- attributes are used. So if you want a Zone without the
Zone component, it's just a matter of knowing to add
data-container-type="zone", and the "core/zone" module.
> Without the abstraction layer I'll need to fork Tapestry and refactor core
> components, I like how you can override almost everythink using the IOC but
> when it is inside component there is nothing you can do.
But if the component is simple enough, you can create a custom one
that does exactly what you want. I think people too often twist
themselves, and their code, into knots trying to customize an existing
component rather than write a few lines of code to create a new one.
>
> If you ask, why did I choose to rewrite javascript logic, it is because I
> think tapestry should not build own javascript framework/library with all
> that wrappers and helpers, I can only understand using requireJS to load
> javascript dependencies. Tapestry javascript support should be one small
> minified file. Why to have all that modules when everyone could just
> contribute to the main core module? What are advantages of using
> jsSupport.require("core/zone") instead of jsSupport.require("core")? Why to
> have modules like "core/spi", "core/console", "core/events"? I would use
> requireJS to have modules "jQuery", "underscore", "tapestry-core",
> "tapestry-core-53-compatibility".
>
The small modules are more pleasant to develop, and easier to debug.
By the time we ship, we'll have a strategy to aggregate (and minimize)
some or all of the modules into a stack. In addition, small modules
make monkey patching (by contributing ShimModules to the ModuleManager
service) easier. Don't like how core/alerts works? Create a
substitute implementation and contribute it.
The module approach is also useful for the way we're tackling some
localization issues, as certain modules are locale-specific (and even
dynamically generated).
> My philosophy is to have simple javascript using pure jQuery without wrappers
> around ajax, console etc. and using events as the interface between different
> parts.
That becomes a key question: we would not need the core/spi layer if
we just said "Tapestry uses jQuery, live with it". As I've said in the
past, that is not the best solution for everyone, but I'm willing to
entertain more discussion on this. It would certainly be easier to
eliminate core/spi.
>
> Denis
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
--
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
