While there might be a benefit to one subroutine call, part of the control over the templates _IS_ due to having a routine for each block of the program.
I purposely avoided removing them in my original proposal. My original thoughts were to simplify the maintennance of the site and redundant code that had to change with minor look-and-feel changes to the site. By keeping the various load template calls in separate subroutines, you've blocked the program off into sections with control over each of the routines, and the ability to override them easily. Not every routine would really know what to do with each set of passed parameters, and as the program gets more complex, it might cause problems.
A data/control array puts all the parameters in one easy to see area. The various subroutine calls make it easy to see the flow of the program. When you start replacing too many parameters that don't really improve the quality of life (so to speak) you can start making things harder (code harder to maintain) than easier (site easier to maintain).
If you look at what I suggested, you could do pretty much the same thing by editing the array, and setting a few additional parameters to be passed in the data array.
That might eventually simplify the subroutines to one call, and a hash reference, but it needs to be done in stages.
It looks like we are tackling the problem from opposite ends.
As for the code:
Code:
if (open (INC, "/../cgi-bin/admin/templates/$1"))
Again, that is an IMPOSSIBLE path.
It says start at the top, go one level up, to heaven, then start looking for the file.
I've got to believe that that _is_ a problem, since that path doesn't exist.
I didn't think nested tags were allowed, but your first post seemed to indicate that the nesting was being properly parsed:
ie - you got the error message:
Code:
Can't find file: ....../abc.html
which would indicate that the filename _was_ being passed, but that the system couldn't find it ... that's a PATH problem.
I haven't tried to do this, I've been working on the user features first. File uploads are next. Maybe Alex has an answer, but the only time a path of:
/../some/other/path
would work, is if it's being appended to another path such as:
$Links{'build_root_path'}/../some/other/path
But the links variable needs to be defined absolute to the file system root.
"open" is a system call, and all it does is assign the filehandle INC to the path you give it. The path you are passing is invalid.
Unless I'm missing something really, really basic, or "open" has been overloaded in some way, that has to be a problem.
My initial reaction was that nested tags like <%include <%filename%>%> wouldn't work, but as I indicated, YOU indicated that part was working, so it has to be a path. Looking at the code fragment, there is no attempt to parse the <%filename%> tag