--243959241-898558662-1316214637=:41801
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
why do i need a web app? becuase of size of my project? I mean if it is goi=
ng to be=A0 a very big website with lot of pages and tables etc. should i h=
ave a webapp?
=0Aapache and cgi wont cut it? (alongwith other technolo=
gies used commonly in websites)
--243959241-898558662-1316214637=:41801--
On Fri, Sep 16, 2011 at 6:10 PM, Rajeev Prasad
> why do i need a web app? becuase of size of my project? I mean if it is g=
oing to be=A0 a very big website with lot of pages and tables etc. should i=
have a webapp?
>
> apache and cgi wont cut it? (alongwith other technologies used commonly i=
n websites)
I think it depends what you are looking for. I tend to believe you can
have either static pages or dynamic pages. Dynamic meaning:
communicating with a database while making the user experience more
interactive instead of your typical static pages. I can think of
several reasons for a web app and it isn't because of the size of a
website, but instead how dynamic you want it to be. I don't have much
experience with cgi but I do with apache and php. I am now also trying
to learn catalyst since I prefer perl over php.
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
--243959241-844080762-1316275890=:29420
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
with apache and php and backend database you can create as much dynamic con=
tent as you wish. so why would you need to turn it into a web app? will it =
not limit its adaptability to future requirements?
=0AFrom: Chris Stin=
emetz
=0ACc: Perl Beginners
11 11:55 PM=0ASubject: Re: website vs web app
On Fri, Sep 16, 2011 at =
6:10 PM, Rajeev Prasad
app? becuase of size of my project? I mean if it is going to be=A0 a very b=
ig website with lot of pages and tables etc. should i have a webapp?=0A>=0A=
> apache and cgi wont cut it? (alongwith other technologies used commonly i=
n websites)
I think it depends what you are looking for. I tend to bel=
ieve you can=0Ahave either static pages or dynamic pages. Dynamic meaning:=
=0Acommunicating with a database while making the user experience more=0Ain=
teractive instead of your typical static pages. I can think of=0Aseveral re=
asons for a web app and it isn't because of the size of a=0Awebsite, but in=
stead how dynamic you want it to be. I don't have much=0Aexperience with cg=
i but I do with apache and php. I am now also trying=0Ato learn catalyst si=
nce I prefer perl over php.
--243959241-844080762-1316275890=:29420--
On Fri, Sep 16, 2011 at 7:10 PM, Rajeev Prasad
> why do i need a web app? becuase of size of my project? I mean if it is g=
oing to be a very big website with lot of pages and tables etc. shoul=
d i have a webapp?
Could you please explain what you mean by "website" [sic] and "web
app" [sic]? The meaning of each will vary by context and audience.
--=20
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 09/16/2011 06:10 PM, Rajeev Prasad wrote:
> why do i need a web app? becuase of size of my project? I mean if it is going to be a very big website with lot of pages and tables etc. should i have a webapp?
>
> apache and cgi wont cut it? (alongwith other technologies used commonly in websites)
What do you mean by "web app"? The most common definition of that
concept is an "application with an exposed HTTP interface" - and you
need one if you choose to offer one. If you don't want to offer an app
over the web, you don't need one.
Now -- I have one client who chooses to offer two different "aspects" of
the same back end data -- a "website" variant designed for humans using
browsers, and a "webapp" variant tailored to developers who want a more
"machine friendly" source of the data, and, in fact, the "website"
instance of Apache uses the same "webapp" server that outside clients use.
This has a certain architectural charm - and most importantly allows to
totally disjoint teams to maintain the two disparate code bases ( the
backend is all DBIx::Class and XML::LibXML, while the front-end is more
LibXML and a bunch of Mason - having been converted from a giant mess of
java and XSLT)
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
--00151744102e885ca204ad2943d9
Content-Type: text/plain; charset=ISO-8859-1
On Sep 17, 2011 1:13 PM, "Brandon McCaig"
>
> On Fri, Sep 16, 2011 at 7:10 PM, Rajeev Prasad
> > why do i need a web app? becuase of size of my project? I mean if it is
going to be a very big website with lot of pages and tables etc. should i
have a webapp?
>
> Could you please explain what you mean by "website" [sic] and "web
> app" [sic]? The meaning of each will vary by context and audience.
>
Darn it, you and Lawrence beat me to it...
At any rate, make you a web 2.0 app in the cloud and fend off tons of APT.
Any buzz words I left out? Virtualization is so 2000 so I figured I could do
without
Here, let me try to help some: nytimes ok for general articles, wired isn't
good for much, popular science is good for general science, etc. Uri has
said to stay away from google when trying to learn how to program and good
technique. While I disagree with this in general I would say that if you
don't know the author, forum, or topic you're as likely to get absolute
bullshit as not.
It seems you've read an article written by a non technical person or idiot
(one in the same maybe ;-) ) and decided to apply a *lame* term to a
technical list.
Webapp, really? And the difference between a web application and a CGI
script 15 years ago? JavaScript maybe? Nope, not even that - ecmascript was
already a standard. So, the difference might be that my cell phone has 100x
the bandwidth my computer had access to 15 years ago. Heh, I doubt even
that. I think the issue is that Americans got lazy once again (I love my
kin) and thought typing app would save .... something (time, keyboards,
discs, lives) who knows. But really, who cares. Technology has evolved in
this space a bit but nothing revolutionary. I like json a shit ton better
than soap (or other xml stuff), web browsers have gotten better, apache has
gotten more bloated and I now have learned to favor nginx, mysql still does
tons of stupid shit and most web sites still use it (?), etc.
Lastly, if you have a bit site with tons of mainly dynamic content, you must
be making major $$$ because you're going to be using tons of your resources
to serve up (and develop, secure, and maintain) that content. No matter
what, your jquery library should be static and perl should not touch it. CSS
should generally be static (maybe you want to fix some browser issues - I
wouldn't but whatever).
Here's what you have, no matter what you do: a CGI, HTTP/1.1 (max) web site.
That's it. You can put tons of stuff on the front end, tons more on the back
end. But nothing you do will change that. This is 20 year old tech and it'll
probably be another 10 years before either of these two things are upgraded.
--00151744102e885ca204ad2943d9--
On 17/09/2011 20:10, Lawrence Statton wrote:
> On 09/16/2011 06:10 PM, Rajeev Prasad wrote:
>> why do i need a web app? becuase of size of my project? I mean if it
>> is going to be a very big website with lot of pages and tables etc.
>> should i have a webapp?
>> apache and cgi wont cut it? (alongwith other technologies used
>> commonly in websites)
>
> What do you mean by "web app"? The most common definition of that
> concept is an "application with an exposed HTTP interface" - and you
> need one if you choose to offer one. If you don't want to offer an app
> over the web, you don't need one.
>
> Now -- I have one client who chooses to offer two different "aspects" of
> the same back end data -- a "website" variant designed for humans using
> browsers, and a "webapp" variant tailored to developers who want a more
> "machine friendly" source of the data, and, in fact, the "website"
> instance of Apache uses the same "webapp" server that outside clients use.
>
> This has a certain architectural charm - and most importantly allows to
> totally disjoint teams to maintain the two disparate code bases ( the
> backend is all DBIx::Class and XML::LibXML, while the front-end is more
> LibXML and a bunch of Mason - having been converted from a giant mess of
> java and XSLT)
Given that this is a Perl list,
huh?
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 09/17/2011 08:51 PM, Rob Dixon wrote:
> On 17/09/2011 20:10, Lawrence Statton wrote:
>> On 09/16/2011 06:10 PM, Rajeev Prasad wrote:
>>> why do i need a web app? becuase of size of my project? I mean if it
>>> is going to be a very big website with lot of pages and tables etc.
>>> should i have a webapp?
>>> apache and cgi wont cut it? (alongwith other technologies used
>>> commonly in websites)
>>
>> What do you mean by "web app"? The most common definition of that
>> concept is an "application with an exposed HTTP interface" - and you
>> need one if you choose to offer one. If you don't want to offer an app
>> over the web, you don't need one.
>>
>> Now -- I have one client who chooses to offer two different "aspects" of
>> the same back end data -- a "website" variant designed for humans using
>> browsers, and a "webapp" variant tailored to developers who want a more
>> "machine friendly" source of the data, and, in fact, the "website"
>> instance of Apache uses the same "webapp" server that outside clients
>> use.
>>
>> This has a certain architectural charm - and most importantly allows to
>> totally disjoint teams to maintain the two disparate code bases ( the
>> backend is all DBIx::Class and XML::LibXML, while the front-end is more
>> LibXML and a bunch of Mason - having been converted from a giant mess of
>> java and XSLT)
>
> Given that this is a Perl list,
>
> huh?
>
sorry -- I didn't realize you'd never heard of DBIx::Class and the other
modules from CPAN I mentioned above (okay -- I used it's common name
Mason, not it's precise package name HTML::Mason -- sue me)
Those are all Perl modules that I've used when writing web application
services and web sites.
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 18/09/2011 04:04, Lawrence Statton wrote:
> On 09/17/2011 08:51 PM, Rob Dixon wrote:
>> On 17/09/2011 20:10, Lawrence Statton wrote:
>>> On 09/16/2011 06:10 PM, Rajeev Prasad wrote:
>>>> why do i need a web app? becuase of size of my project? I mean if it
>>>> is going to be a very big website with lot of pages and tables etc.
>>>> should i have a webapp?
>>>> apache and cgi wont cut it? (alongwith other technologies used
>>>> commonly in websites)
>>>
>>> What do you mean by "web app"? The most common definition of that
>>> concept is an "application with an exposed HTTP interface" - and you
>>> need one if you choose to offer one. If you don't want to offer an app
>>> over the web, you don't need one.
>>>
>>> Now -- I have one client who chooses to offer two different "aspects" of
>>> the same back end data -- a "website" variant designed for humans using
>>> browsers, and a "webapp" variant tailored to developers who want a more
>>> "machine friendly" source of the data, and, in fact, the "website"
>>> instance of Apache uses the same "webapp" server that outside clients
>>> use.
>>>
>>> This has a certain architectural charm - and most importantly allows to
>>> totally disjoint teams to maintain the two disparate code bases ( the
>>> backend is all DBIx::Class and XML::LibXML, while the front-end is more
>>> LibXML and a bunch of Mason - having been converted from a giant mess of
>>> java and XSLT)
>>
>> Given that this is a Perl list,
>>
>> huh?
>>
>
> sorry -- I didn't realize you'd never heard of DBIx::Class and the other
> modules from CPAN I mentioned above (okay -- I used it's common name
> Mason, not it's precise package name HTML::Mason -- sue me)
>
> Those are all Perl modules that I've used when writing web application
> services and web sites.
Please forgive me - I am far from inexperienced but I understand little
of what you have written. I hope your post helps the OP, but to me it
reads like a promotion brochure.
I am very familar with the Perl modules you mentioned (in parentheses at
the end of your final paragraph) but what help do you think you can
offer to Rajeev?
Rob
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
--00151744822a667eb404ad2fa3e0
Content-Type: text/plain; charset=ISO-8859-1
On Sep 17, 2011 11:44 PM, "Rob Dixon"
>
> On 18/09/2011 04:04, Lawrence Statton wrote:
> I am very familar with the Perl modules you mentioned (in parentheses at
> the end of your final paragraph) but what help do you think you can
> offer to Rajeev?
>
Probably none. His question wasn't a very good one.
Though, I wonder now whether your point here isn't just to piss people off?
(Rhetorical BTW)
--00151744822a667eb404ad2fa3e0--
On 18/09/2011 05:27, shawn wilson wrote:
> On Sep 17, 2011 11:44 PM, "Rob Dixon"
>>
>> On 18/09/2011 04:04, Lawrence Statton wrote:
>
>> I am very familar with the Perl modules you mentioned (in parentheses at
>> the end of your final paragraph) but what help do you think you can
>> offer to Rajeev?
>>
>
> Probably none. His question wasn't a very good one.
Then I suggest that he should be helped to create a better question.
> Though, I wonder now whether your point here isn't just to piss people off?
> (Rhetorical BTW)
I likewise am wondering rhetorically at the reason for that comment.
Rob
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
On 17/09/2011 00:10, Rajeev Prasad wrote:
>
> why do i need a web app? becuase of size of my project? I mean if it
> is going to be a very big website with lot of pages and tables etc.
> should i have a webapp?
>
> apache and cgi wont cut it? (alongwith other technologies used
> commonly in websites)
Just to clarify my position, I too am unclear about what a web
application might be. I can certainly imagine what people might mean by
the term, but nothing that has been posted here has helped me.
I suspect that it can describe a multitude of architectures, with or
without an intermediate HTTP server layer, but I cannot judge whether
Perl is a practical tool for anything like that.
Those who have experience in this area will no doubt consider me a fool
as it is all second nature to them, but I urge them to curb their mirth
and instead pass on their wisdom to the majority here who can only hope
to be as accomplished.
Rob
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/
--1091894413-710091023-1316358816=:79978
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
From: Lawrence Statton
: Saturday, September 17, 2011 2:10 PM=0ASubject: Re: website vs web app=0A=
=0AOn 09/16/2011 06:10 PM, Rajeev Prasad wrote:=0A> why do i need a web app=
? becuase of size of my project? I mean if it is going to be=A0 a very big =
website with lot of pages and tables etc. should i have a webapp?=0A>=A0 a=
pache and cgi wont cut it? (alongwith other technologies used commonly in w=
ebsites)
What do you mean by "web app"?=A0 The most common definition =
of that concept is an "application with an exposed HTTP interface" - and yo=
u need one if you choose to offer one.=A0 If you don't want to offer an app=
over the web, you don't need one.
Now -- I have one client who choose=
s to offer two different "aspects" of the same back end data -- a "website"=
variant designed for humans using browsers, and a "webapp" variant tailore=
d to developers who want a more "machine friendly" source of the data, and,=
in fact, the "website" instance of Apache uses the same "webapp" server th=
at outside clients use.
This has a certain architectural charm - and m=
ost importantly allows to totally disjoint teams to maintain the two dispar=
ate code bases ( the backend is all DBIx::Class and XML::LibXML, while the =
front-end is more LibXML and a bunch of Mason - having been converted from =
a giant mess of java and XSLT)
=============3D=
===================
choosing =
to reply to Statton's email:
=0A"web app services" does make a whole l=
ot more sense then just saying web-app. I have seen many people/perl-websit=
e for catalyst/books on this subject, just calling it web app, rather then =
web app services. (I think IBM call theirs web services, which is more mean=
ingful term).
=0Aso once the distinction is set, original question is =
not very useful. as some people may be wanting to deal with a website's dat=
a dished out as services over HTTP (API which uses HTTP), rather than scrap=
ing the web-page for information.
=0Aif we have data in database and w=
e can process it using sql why cant we just offer access to that data direc=
tly - with all security and business logic builtin? is this not the age old=
issue of how to store and offer data, for which databases were invented? a=
re we just re-inventing the wheel? adding another complex code on top of ma=
ny layers of code?
=0Ahave=A0i totally missed the point here?=0Athx.
--1091894413-710091023-1316358816=:79978--
On Sun, Sep 18, 2011 at 11:13 AM, Rajeev Prasad
> if we have data in database and we can process it using sql why
> cant we just offer access to that data directly - with all
> security and business logic builtin? is this not the age old
> issue of how to store and offer data, for which databases were
> invented? are we just re-inventing the wheel? adding another
> complex code on top of many layers of code?
There are a few reasons. Access to the database requires database
credentials. Even if the data is freely readable and writable by
anonymous users, you still can't allow anonymous users to freely
modify the database structure, or drop the database entirely. :)
You could make an 'anonymous' user and ONLY grant them privileges
to execute "safe" stored procedures that implement all of the
business logic, making it safe to allow anyone to execute them.
However, that is very difficult to do, and even more difficult to
manage properly. SQL is a rather rudimentary language, designed
as a _query_ language. It's more difficult to implement business
logic in SQL than in a higher level language like Perl or Java,
IMHO.
There are other considerations too. If you grant the world direct
access to your database management system then any flaw in your
database setup or even the database management system itself will
leave all of your data completely vulnerable to corruption or
loss. A flaw in your application could do the same thing, but I
guess the extra layer of abstraction just makes things a little
bit safer. It's also easier to write safety-layers in application
code to greatly reduce the number of human errors that can have
such a drastic effect. For example, using a parameter-based API
to feed unsafe data into SQL, rather than manually concatenating
a SQL string.
The abstraction also makes it easier to make database structure
changes without affecting the world. You could change the
structure of your database, or your stored procedures, and keep
the public Web service API the same; meaning that nobody else
needs to rewrite their code. The opposite is true also: you can
easily add new Web service calls without any changes to the
database. In fact, you don't technically even need to have a
database at all. For all anybody using the service knows, the
data could be stored in plain XML files, or could be coming from
a third party. They don't know how or where it's stored and they
shouldn't need to. All they need to know is the Web service API
that you expose.
A Web service is basically intended for machine interaction. A
Web site is typically used for direct human interaction.
Technically both can be used by either, but it's more difficult
to do. Whether or not you should implement a Web service depends
on the type of site that you're creating, and the value of
exposing the services (if any) directly to machines. Similarly,
you only need to create a Web site (i.e., human-centric) if
humans are actually going to directly access your information or
interact with your services. Having both is certainly ideal, but
you have to evaluate the cost of development (and maintenance)
against the practical benefits.
--
Brandon McCaig
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software
--
To unsubscribe, e-mail: beginners-unsubscribe@perl.org
For additional commands, e-mail: beginners-help@perl.org
http://learn.perl.org/