dalini wrote:
Michael Bell wrote:
The next issue is the access control. What controls the access
(OpenCA::UI or OpenCA::Server) and what is controlled (API access or
UI usage). Questions over questions. Perhaps I have in mid january a
running server for evaluation.
this depends, if the ui uses
Michael Bell wrote:
The next issue is the access control. What controls the access
(OpenCA::UI or OpenCA::Server) and what is controlled (API access or UI
usage). Questions over questions. Perhaps I have in mid january a
running server for evaluation.
this depends, if the ui uses the api too, j
Hi Michael,
>> # Private methods
>> $self->{PRIVATE}->{bar} =
>> sub {
>>...
>> };
> This looks really ugly. Usually I use functions to give the code a
> better structure. If we use this way to define functions then we can
> forget about the function and simply write one big f
Hi Martin,
first, it is common practice to begin functions that are meant to
be private with an underscore. A caller could, of course, call such
a function, but it is widely known among Perl hackers that this
is Not Good.
I already do this.
package foo;
sub new {
my $proto = shift;
my $class =
Hi Michael,
> Perl has no real object oriented features today. So it is not possible
> to declare private and public functions within the server.
first, it is common practice to begin functions that are meant to
be private with an underscore. A caller could, of course, call such
a function, but i
Hi all,
I am actually coding the API. I have a small question to developers and
advanced customers too. After a first phase I have a class
OpenCA::Server and a class OpenCA::UI::HTML. The objects in
OpenCA::UI::HTML access the functions in OpenCA::Server directly.
Perl has no real object orient
