I would like to ask that following rule be set for weblocks:

Weblocks functions should not generate any user-visible strings, or
if they do, the content should be easy to supply/override.

What I mean is that at present weblocks has embedded strings, things
like:

formview.lisp, with-view-header fragment:

                   (:span :class "slot-name"
                          (:span :class "extra"
                                 (unless (empty-p (view-field-label field))
                                   (str (view-field-label field))
                                   (str ": "))
                                 (when (form-view-field-required-p field)
                                   (htm (:em :class "required-slot" 
"(required) "))))))

Observe the ": " and "(required) ". Both are a problem for me
at this time.

or

(defmethod view-caption ((view form-view))
  (if (slot-value view 'caption)
      (slot-value view 'caption)
      (with-html-output-to-string (out)
        (:span :class "action" "Modifying: ")
        (:span :class "object" "~A"))))

or the silly (:h2 :class "form-fields-title" "Form fields:") message
that I removed and Stephen added back in -dev.

These are all a problem. Some of those are killable by setting CSS
"display:none", but that requires cooperation with CSS designers and
maintaining that, plus we impose a gratuitous overhead of HTML that will
never be displayed. I don't think it makes sense. Some of those, like
the "(required)" message are a problem for non-english sites. Some of
those, lke the ": " are a problem for other reasons.

In any case, most of them are gratuitous (e.g. we could live without
them), useful mostly for simple demos and difficult to override. I don't
buy into the "subclass the whole whing and define your own method"
argument -- I don't want to maintain a dozen or so full rendering
methods in my app just to override a couple of strings.

I believe we should follow a rule -- generating HTML markup is fine,
generating user-visible strings is not. If we do include them, they
should be generated by the application, or should be easy to override by
the application.

Please note that I don't believe simply wrapping them all in some sort
of #t() internationalization thing is the solution [1].

I realize this is a lot of work and it will break most tests (they
expect full HTML, which I think is an issue as well), but let's set
ground rules and work on it gradually. That way our patches won't
conflict and people that develop non-english sites will have an easier
job.

--J.

[1]
http://groups.google.com/group/weblocks/browse_thread/thread/2d2cbb050a31e06d/b7cde8c2e7bde66a?lnk=gst&q=i18n



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to