The constructs suggested in the original email are similar if not identical to
embperl's (or php's for that matter), I was merely pointing out that we shouldn't
probably reinvent the wheel with yet another pseudo-scripting language.
The embperl page needs not contain the actual perl code to pro
You're missing the point of separating the code and the interface.
On Thu, Aug 10, 2000 at 10:00:48AM -0700, L.C. wrote:
>
> You may want to take a look at Embedded Perl (Embperl), it does EXACTLY what
> you are asking and much more, it is a very good tool for building interfaces
> in perl. http
It may not be very portable either -- a fair number of us aren't running
Apache.
-Original Message-
From: David Harris
Sent: Thursday, August 10, 2000 10:59 AM
To: L.C.; [EMAIL PROTECTED]
Subject: RE: Modular Client Code Proposal
L.C. wrote:
> You may want to tak
L.C. wrote:
> You may want to take a look at Embedded Perl (Embperl), it does EXACTLY what
> you are asking and much more, it is a very good tool for building interfaces
> in perl. http://perl.apache.org/embperl/index.html
>
> You can then include separate header files too, although you realize t
You may want to take a look at Embedded Perl (Embperl), it does EXACTLY what
you are asking and much more, it is a very good tool for building interfaces
in perl. http://perl.apache.org/embperl/index.html
You can then include separate header files too, although you realize that you
will eventual
Joe Rhett wrote:
> To be honest, one of the huge problems OpenSRS has is the dependancy upon
> the template names - template names in templates right beside template names
> in the code.
>
> If you designed it better, you wouldn't need to have any template names in
> the code at all -- absolutely
To be honest, one of the huge problems OpenSRS has is the dependancy upon
the template names - template names in templates right beside template names
in the code.
If you designed it better, you wouldn't need to have any template names in
the code at all -- absolutely no dependacies. The template
These are all very nice, but I've seen a great many "modular" systems built
which end up completely unmaintainable due to the lack of foresight of the
programmers. To be honest, I'm not very impressed with OpenSRS code to
date:
1. The code must known exactly what's in the templates and where it i
Charles Daminato <[EMAIL PROTECTED]> said:
> I've been working on this for some time - but since I'm not a 'programmer'
> per se, don't mind the terms I'm using. I expect full feedback on the
> list for this discussion - try to keep it pertinent instead of trying to
> get 'new' features added as
At 08:44 PM 8/9/00 +, you wrote:
>Charles,
>
>While I think this is a great idea - and I mean that, I'm not just being
>obsequious - I also think that you're mixing up your priorities. The most
>important next step for OpenSRS should be to document the API completely,
>from start to finish.
T
Points very well taken. A well documented API is first.
What we are talking about is beyond that.
Regards,
sA
At 02:32 PM 8/9/00 -0400, you wrote:
>My suggestion - and this is a very serious suggestion - is that
>Tucows/OpenSRS not spend time developing fancy client code. In fact,
>I would p
On Wed, Aug 09, 2000 at 11:34:45AM -0400, Charles Daminato wrote:
> With each new feature we add to OpenSRS we find ourselves forced to
> release a complete version of the client code. Due to severe
> customizations that certain customers have made it becomes increasingly
> difficult for you to i
Comments intertwined below, enclosed in double angle-brackets
<<
like this...
>>
Regards,
Eric Longman
Atl-Connect Internet Services
+---+
| Atl-Conn
My idea was to have pertinent naming schema for the templates. That way
managing several directories wouldn't be a problem.
I.E. manage_login.template, base.template, batch_reg_verify.template
Stuff like that :) Making a spec for template schema might be just as
difficult and involved as creat
Charles Daminato wrote:
>
> Templates - each new module may need new templates. The proposal is to
> have a base template infrastructure (base.html, header.html, footer.html,
> etc) and specific APTLY named templates for each new feature and customer
> facing screen that encompasses the logic of
15 matches
Mail list logo
