At 01:24 PM 10/30/2001 +0100, you wrote: >Mike Heins <mheins@redhat.com> writes: > > > Quoting Stefan Hornburg (Racke) (racke@linuxia.de): > > > > > > Is there any reason that this is tag is widely mentioned in the docs ? > > > I thought it is deprecated and can be replaced by other means. > > > > Because I did a good job of documenting that one and it was never > > undocumented. > >Fine, but we can it take out now or not ? > >Ciao > Racke At this point I would not consider it useless, as I don't see any other way of sorting lists that don't come from search results, besides in-page perl code. In particular, the sorting of [item-lists] comes to mind. In any case, [sort] is the only general-purpose sorting mechanism in ITL that I know of (please correct me if I am wrong here), and for that reason alone I think it is worth preserving. Perhaps we can adjust the docs to de-emphasize the use of [sort] for searches in favor of tf/to and just keep the examples for [item-list] and [loop]. - Ed L.
Ed LaFrance <edl@newmediaems.com> writes: > Hello core dwellers - > > Being the new kid on the block, I wondering if someone has a project they > would like to delegate to me - preferably not too complicated to start? Uuh, not complicated. That's complicated with Interchange :-) Of which parts of Interchange you have a deeper knowledge ? Ciao Racke -- Racke happily hacks Interchange and maintains Debian packages like Courier. For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: info@cobolt.net; Phone: 0041-1-3884400)
Quoting Stefan Hornburg (Racke) (racke@linuxia.de): > Mike Heins <mheins@redhat.com> writes: > > > Quoting Stefan Hornburg (Racke) (racke@linuxia.de): > > > > > > What can be said on the performance on the calc and perl tags. > > > They appear pretty similar. What are the differences ? > > > > Calc is lower-overhead because it doesn't pre-open database tables > > or do any extra wrapping of stuff. > > Ah, thanks very much. Do you know if this is mentioned in the > documentation ? Yes, right where you would expect: http://interchange.redhat.com/cgi-bin/ic/docfly.html?mv_arg=ictags04%2e08 -- Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH 45013 phone +1.513.523.7621 <mheins@redhat.com> Fast, reliable, cheap. Pick two and we'll talk. -- unknown
The last "authoritative" statement on code standards was done about a year
ago, and is still on the Akopia Wiki. Basically perlstyle was formally
adopted and a few trivial additions made.
I like the way cuddled elses visually unify the whole control flow. But
even an else-cuddling diehard like me can change, if that's what people
want. :)
Jon
Programming Standards
(MikeHeins, JeffBarr, EricZarko, SonnyCook)
The following notes document a meeting that took place on November 14,
2000.
Introduction - We agreed that it is good to have a programming style, and
that the existing style of code should be preserved. We agreed that making
global changes to impose a consistent style is not worth doing. Instead,
we will make revisions as we rewrite code. We will generally follow the
published Perl style guidelines, and we will use 4 character tabs.
Else - We accept but do not encourage the use of the "cuddled else"
construct ("} else {" on a single line).
Lexical Issues - White space is free, and white space around operators
increases readability. Lining up the "=" in a series of assignments can be
used to emphasize the parallel structure.
Naming - Package globals should start with a capital letter. In other
situations, avoid StudlyCaps where names begin with a capital letter.
Items in the main package should be referenced as "$::Foo", not
"$main::Foo".
Globals - Global variables and subs should be used very sparingly.
Occasionally it is necessary to use global variables as implicit arguments
to certain subs for efficiency purposes. We should not add more globals,
and we should consider removing existing ones. An important exception are
certain subs such as logGlobal, logDebug, errmsg, and logError.
CVS - CVS comments should be meaningful. As a matter of good programming
practice, we encourage a careful review of all diffs before committing
changes to CVS. When committinga large number of files (possibly
containing changes and fixes to multiple areas) it is best to create
file-specific comments addressing individual fixes. Using a blanket
comment is not encouraged.
Loops - We prefer to declare loop control variables immediately prior to
the beginning of the loop:
my $var;
foreach $var () {
...
}
Bugzilla - We encourage the use of Bugzilla as a work queuing tool.
Entering and tracking all bugs, even those you find and then fix yourself,
is a good practice. Creating a relationship between a CVS commit and a
Bugzilla entry by listing the bug number in the CVS log message and the
file names in the Bugzilla entry is encouraged.
mheins@redhat.com writes: > Quoting Stefan Hornburg (Racke) (racke@linuxia.de): > > > > How can I check if an Interchange page server is running properly or > > is stuck in a loop ? > > Kill it, even with a 0. If it responds, it is alive. Ah, OK. That's a cute idea. Ciao Racke -- Racke happily hacks Interchange and maintains Debian packages like Courier. For projects and other business stuff please refer to COBOLT NetServices (URL: http://www.cobolt.net; Email: info@cobolt.net; Phone: 0041-1-3884400)
[cgi foo] in
-&ITL; or $CGI->{foo} in embedded Perl.
+&glos-itl; or $CGI->{foo} in embedded Perl.
__END__
__NAME__ notes
1.8 +6 -6 xmldocs/refs/css
rev 1.8, prev_rev 1.7
Index: css
===================================================================
RCS file: /var/cvs/xmldocs/refs/css,v
retrieving revision 1.7
retrieving revision 1.8
diff -u -r1.7 -r1.8
--- css 28 Oct 2004 10:29:14 -0000 1.7
+++ css 9 Nov 2004 23:16:16 -0000 1.8
@@ -16,7 +16,7 @@
[userdb function=delete_cart
nickname=CART_NAME ].
1.5 +2 -2 xmldocs/refs/download
rev 1.5, prev_rev 1.4
Index: download
===================================================================
RCS file: /var/cvs/xmldocs/refs/download,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- download 16 Oct 2004 18:13:47 -0000 1.4
+++ download 9 Nov 2004 23:16:16 -0000 1.5
@@ -17,8 +17,8 @@
__NAME__ description
-The main function of this &pragma; is to prevent any
-&interpolation; of the output.
+The main function of this &glos-pragma; is to prevent any
+&glos-interpolation; of the output.
It helps to preserve the downloads intact if they
happen to contain constructs similar to
[flag checkhtml] on your page,
(or wrap only a block of HTML code to check in
[tag flag checkhtml]...[/tag])
to trigger the actual invocation of the specified external command.
__CHECK_HTML__
on every page (or ideally, in a template). Then, to enable the
checker, define Variable CHECK_HTML [flag checkhtml] in
&gcf;. To disable it, leave the variable value empty.
__END__
__NAME__ notes
Leaving this directive enabled on a production server usually leads to
unneccesary performance degradation. The additional process spawn
(and the time it takes to complete) every time a page is visited is
very costly.
__END__
__NAME__ example
[cgi foo] in
-&glos-itl; or $CGI->{foo} in embedded Perl.
+&glos-ITL; or $CGI->{foo} in embedded Perl.
__END__
__NAME__ notes
1.5 +2 -1 xmldocs/refs/no_html_comment_embed
rev 1.5, prev_rev 1.4
Index: no_html_comment_embed
===================================================================
RCS file: /var/cvs/xmldocs/refs/no_html_comment_embed,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- no_html_comment_embed 9 Nov 2004 23:16:16 -0000 1.4
+++ no_html_comment_embed 20 Nov 2004 14:40:40 -0000 1.5
@@ -17,7 +17,8 @@
__NAME__ description
-Many &glos-HTML; editing applications do not support &glos-itl; directly, and some
+Many &glos-HTML; editing applications do not support &glos-ITL; directly, and
+some
(thinking it doesn't belong to the page) ruin your work. This is
understandable to an extent, because some ITL tags (such as Hello, World!
The time is now [time].
For any trouble with this Interchange catalog, please email [filter mailto]root@myhost.mydomain.local[/filter].
1.27 +239 -89 xmldocs/guides/iccattut.xml rev 1.27, prev_rev 1.26 Index: iccattut.xml =================================================================== RCS file: /var/cvs/xmldocs/guides/iccattut.xml,v retrieving revision 1.26 retrieving revision 1.27 diff -u -r1.26 -r1.27 --- iccattut.xml 16 Nov 2004 16:35:10 -0000 1.26 +++ iccattut.xml 22 Nov 2004 22:26:12 -0000 1.27 @@ -94,21 +94,22 @@ Those who want to find their way with Interchange, and take on Interchange development equipped with
+
+
+
+Interchange Tag Language (ITL) is a simple and intuitive way of +accessing +Interchange functionality; that's why we chose it for this introductory +course. Other possibilities include direct Perl programming, ASP-like +syntax and combinations of the above, but we'll explain those at a later +time. +
+ ++ITL is a successor to MML, or Minivend Markup Language. +(Up to version 5.x, Interchange was called Minivend). It is of vital +importance that you become familiar with this basic language and its +syntax. As ITL naturally progressed and the ammount of functionality +provided through it grew, it became more and more important to properly +learn the basics. +Mark Stosberg +once put up a theory that MML actually stood for Mere Mortals Language, +while you had to be Information Technology Leader to use ITL. +However, it's not as discouraging as it might seem - stick to our firm +guidance and you'll learn the basics without wasting your time. +
+ ++In a way, ITL and HTML tags are similar - they both take parameters +or attributes, and they can both be standalone or container tags. +
++Standalone tag is one that does not have an ending tag (consequently, +it has no "body"). One such example is the [time] tag; simply placing [time] +on the page displays local time: +
++[/restrict] +[time] +[restrict] +
++Container tags, on the other hand, do have a body. Let's take [filter] +as an example. In [filter op=mailto]root@mydomain.local[/filter], +"root@mydomain.local" is considered the tag's body and placing the +tag on a page produces a mailto link: +
++[/restrict] +[filter op=mailto]root@mydomain.local[/filter] +[restrict] +
++
++Besides being good for a container example, the above [filter] tag also +accepted an attribute. If an attribute is required, or can be specified in +positional order - then it is called a parameter. In our specific case, +the op attribute of the [filter] tag is both required and +positional, so it is a true parameter. (You can't tell which attributes are +required, positional or accepted just by looking at the tag - you need to +consult the appropriate tag's reference page). +
++ Let's see the named and positional approach to specifying parameters + and attributes: +
++
+ It is important to note that you cannot mix positional and named + parameters - each tag individually must be provided either all positional, + or all named parameters. Additionally, some tags look like + container tags when they're not - for example, the closing [/page] tag is + just a macro and not a closing tag to the corresponding [page] + (consequently, the text between [page] and [/page] is not treated + as the body of the [page] tag. +
++
++
++
++
++
++
++
++
+ +For any trouble with this Interchange catalog, -please email [filter mailto]root@myhost.mydomain.local[/filter]. +please email [filter mailto]root@mydomain.local[/filter].