In an attempt to avoid duplication of effort and conflict and risk this being called another duplicate module - are you able to provide more information about how your proposal differs from the widely-used signwriter.module and how it fits into the roadmap of the other dynamic rendering API initiatives?

What features did you need that could not be worked into signwriter?

Comments

azman’s picture

azman commented
Version: » 6.x-1.x-dev

In short; This module was developed by the organization I represent, and it has been suggested that we submit it to the Drupal community in the spirit of Open source. Signwriter and jaf would appear to offer matching features with only one or two differences. Currently jaf provides what we need and regardless of duplication, we will continue to use jaf internally until we have the time, and signwriter becomes an easy alternative to migrate to.

In long; Our original search found no apparent matches to the functionality required in this module and thus we developed it for our own Drupal implementation. This is a shame as obviously we somehow missed signwriter. The Dynamic rendering API module was considered but passed up because we wanted to move away from sIFR (layout and CSS issues with custom theme) and a smaller module with less features that we had full control of was more appealing than developing for the DRAPI.

Regardless, from looking at the signwriter project these are the (tiny) differences that I can see:
1. signwriter allows a developer to change a theme's code to enable replacement text. jaf is configured entirely from the administration menu only.
2. signwriter allows a user to target text by using regular expressions, jaf uses css selectors through JQuery (which IMOHO is arguably a little easier for the lay-person to understand).
3. jaf provides a mouse-over feature whereby an additional style can be linked to an existing - which will display when the targeted items are moused-over

So it would appear that our module does indeed duplicate some of the signwriter functionality. In which case we are happy to remove the project and maintain jaf for our own personal use - outside of Drupal.

dman’s picture

dman commented

Fair enough. I know how easy it is to miss a useful stepping stone in the first pass. It's also pretty cool to develop your own solutions as an exercise - or just because it's a better fit for your immediate needs.

The best-case scenario all-round would maybe be to add or refine some of the signwriter features to meet your requirements.

Signwriter does also support code-based or regexp replacements, but the primary usage in deployment is just using the UI confige to construct text formatting profiles that replace Page titles and Block titles.
The code and regexp are for custom applications beyond those two, which it supports out of the box.

AFAIK, There was some discussion on moving some of the rendering rewrite towards a more jquery-based/client-side thing. That's what the dynamic render API was working towards encompassing - SiFR was to be just one branch of that generic functionality.
The earlier signwriter code was a lot more web-1.0 ... and accessible.

Mouseover support could be looked at. I've done it myself with a branch of signwriter. Using sprites I rewrote a mash-up of menuwriter, signwriter and imageapi. I'm looking for convergence in text rendering, and hope to release textwriter_api to compliment image_api and be a common util for menuwriter, signwriter and imagecache_actions ...
But that's just my thoughts.

At the moment, just identifying that you know the strengths and weaknesses and differences between your mod and signwriter on the project page may be enough to keep you in the clear....

azman’s picture

azman commented

Thanks, In that case - We'll keep this project page up until things change. We'll do a number of things to avoid confusion:
* We'll keep close track of signwriter and drapi and provide links to them from this project's page.
* I'll place a couple of links to signwriter, DRAPI and this issue and point out the alternatives to any one who finds this page.
* We'll continue to make changes to our module as required and send the updates to the Drupal CVS
* When we have the time, we'll take a look at seeing what we can contribute to the other two modules to bring them in to line with our requirements.