Older blog entries for mglazer (starting at number 206)

I am introducing a tangent to PHPortal, Mini-PHPortal.

This application is a standalone one-time build of many PHPortal concepts and JSP/Java Ideas in PHP. What will be added to and changed will be the component libaries themselves.

Mini-PHPortal uses my Xpc Templator (http://4arrow.com/test/t/) and PHPortal (http://sf.net/projects/xpc/) Concepts.

The first release will be the last release (as far as I can tell right now) of the core code.

Here is the abstract: Mini-PHPortal is a Hybrid of PHPortal. Mini-PHPortal combines the structure of Java Beans, with the interface of JSP Custom tags, and the simplicity of PHP in a completely transparent and utterly modular virtual web intreface middleware for the easy use and production of re-usuable software components.

The basic idea is that we use the PHPortal virtual URIs and map them to a local template file directory structure that maps the URIs being requested. Therefore, all URI requests get sent through the main Mini-PHPortal handler.

CODE FLOW: Once the Link is requested and handled Mini-PHPortal maps the request to a flat file directory structure.

The template is then called and any accompanying macro files that template builds with.

The template and macro files are then parsed for special Xpc tags. These tags are references to the applications that are then called an acted upon.

These applications follow a specific code structure. Any application that is referenced whether that is a caching application, administrative, Template editor etc.. all come from the same libraries directory and follow the same patterns.

The directory structure is as follows:

(file).htaccess Sends all URI requests to the index.php file below

(file)index.php Handles all URI requests sent from the .htaccess file, calls the core libs to do the code run on the URI request.

(file)config.php General and global configs. Per site/domain setup is not built-in like PHPortal it would be a separate application in the 'libraries' directory.

(Directory)core/ The core classes that are executed on each URI request.

(Directory)libraries/ All the applications that are referenced within template tags reside here.

(Directory)templates/ The virtual file directory that matches the URI request and has template tag calls to the libraries applications.

The central idea is that everything is a class library that is called by a template tag reference. This would include the actual template editor, template caching, access rights, and the general administration itself.

Besides the above mentioned tools I will try to build before the initial release I will also try to port the Xpc content type transformations but not necessarily as a core class but instead as a component class. Since it is probably bigger than most it will be a good test case to see what to do in large component type application situations.

PHPortal Demo Site with Administration coming soon.

I am working on a partitioned PHPortal demo site that visitors can use to play with the PHPortal administration.

Due to security concerns this may be a bit tricky and therefore take some time. More coming soon as things progress.

I am also getting word of Windows user's bugs and will have to look into that too, my first guess being the cache/ftp.

My New thing is:

Replication of the the basic format and use of Java Beans and Java Custom Tags in JSP for PHP.

This does come into play with PHPortal-Xpc. Specifically with the App Builder.

JBeans and JTags offer a standard protocol in which to write applications, a standard interface in which to reference your formatted apps and a sort of middle-ware to make it all happen.

So what we have is three layers.

1. The parser that interprets and calls the repective references.

2. The formatted class libs/apps.

3. The template that calls the class libs and pass arguments.

I will set up the classic hello world for each as well as a Datetime app samples.

Reading the CGI Variables in JSP:

String AUTH_TYPE	 = request.getAuthType();
Int CONTENT_LENGTH	 = String.valueOf(request.getContentLength());
String CONTENT_TYPE	 = request.getContentType();
String DOCUMENT_ROOT	 = getServletContext().getRealPath("/");
String PATH_INFO	 = request.getPathInfo();
String PATH_TRANSLATED	 = request.getPathTranslated();
String QUERY_STRING	 = request.getQueryString();
String REMOTE_ADDR	 = request.getRemoteAddr();
String REMOTE_HOST	 = request.getRemoteHost();
String REMOTE_USER	 = request.getRemoteUser();
String REQUEST_METHOD	 = request.getMethod();
String SCRIPT_NAME	 = request.getServletPath();
String SERVER_NAME	 = request.getServerName();
Int SERVER_PORT	 = String.valueOf(request.getServerPort());
String SERVER_PROTOCOL	 = request.getProtocol();
String SERVER_SOFTWARE	 = getServletContext().getServerInfo();

Using the above in a JSP page:

<%=request.getServletPath()%>

Ot the XML equivalent of:

<jsp:expression>
request.getServletPath()
</jsp:expression>

Mr. Bean Returns:

BEAN:

public class CurrentTimeBean {
   private int hours;
   private int minutes;

public CurrentTimeBean() { java.util.Date now = new java.util.Date(); this.hours = now.getHours(); this.minutes = now.getMinutes(); }

public int getHours() { return hours; }

public int getMinutes() { return minutes(); } }

JSP:

<jsp:useBean id="time" class="CurrentTimeBean"/>
<HTML>
<BODY>
It is now <jsp:getProperty name="time" property="minutes"/>
      minutes past the hour.

Oh Beano, beano, beano.

21 Aug 2002 (updated 21 Aug 2002 at 01:15 UTC) »

Why use servlets and not beans?

Don't ask me. I use Beans and not servlets.

Servlets and beans are both java Classes. Beans follow a strict class structure.

As far as I can tell Servlets are cool CGI but still have the CGIs secondary nature. In other words you can not easily include a servlet and thus its output in the middle of a JSP page, you would have to use a load expensive SSI call and page.

Beans on the other hand are much more modern and code friendly, meaning no output with code. It allows JSP to be a true web scripting langauge by the pure and true separation of code and design.

Th availability of code within output is smart and useful but also not wise to always be on.

Of course people should be allowed to mix the two but it should be an option that can be turned off for production and live environments.

Sun has a great quick start guide to using JSP:

http://java.sun.com/products/jsp/docs.html

Next: Beans Versus Servlets:

Why, Where, Who, Which, and of course When...

The Difference:

Paranoia is not the fact that people are looking at or talking about you.

Instead, paranoia is being scared by the truth or untruth that people are looking at or talking about you.

You see, a non-paranoid person is not scared if people are looking or talking at or about them, only a truly paranoid person is.

Complete Java Bean; Hello World:

BEAN:

package com.taglib.wdjsp.fundamentals;
public class HelloBean implements java.io.Serializable {
  String name;

public HelloBean () { this.name = "World"; } public String getName () { return name; } public void setName (String name) { this.name = name; } }

JSP:

<HTML>
<BODY>
<jsp:useBean id="hello" class="com.taglib.wdjsp.fundamentals.HelloBean"/>
<jsp:setProperty name="hello" property="name" param="name"/>
Hello, <jsp:getProperty name="hello" property="name"/>!
</BODY>
</HTML>

197 older entries...

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!