[PJUG Javamail] Consumer Based Web Development

Fri Jan 8 15:07:35 EST 2010

That makes perfect sense. I don't think for the cases that need to be
indexed that any of this phases are necessary. They will be for the shopping
cart, but that doesn't need to be indexed, so I think we are good.

Thanks again.
--
James R. Perkins
http://twitter.com/the_jamezp

On Fri, Jan 8, 2010 at 12:02, Ken Paulsen <Ken.Paulsen at sun.com> wrote:

>
> No requests do not *have* to be a POST in JSF.  However, when you make GET
> requests the lifecycle is simplified since there is nothing was POST'ed to
> the server,  It does not go through the "submit request values" phase, or
> validation, or update model, etc.  It basically goes directly to the
> rendering phase for the URL that you requested.  As long as that makes
> sense... you'll be fine.  ;)
>
>
> Good luck!
>
> Ken
>
> James Perkins wrote:
>
> I would love to move to GlassFish, but we are an IBM i (AS/400) consulting
> firm and I'm not sure how to get it running. I think we can through an
> environment called PASE (it's an AIX style environment), but I'm not too
> familiar with how all that works.
>
> Oh brilliant. I didn't realize you parametrize JSF like that. I was,
> wrongly, under the assumption that it HAD to be POST because of the life
> cycle. So if that's the case I don't we have any problems at all.
>
> Thanks a bunch Ken!
> --
> James R. Perkins
> http://twitter.com/the_jamezp
>
>
> On Fri, Jan 8, 2010 at 11:29, Ken Paulsen <Ken.Paulsen at sun.com> wrote:
>
>>
>> Ok, I see why you are where you are. :)  If your boss is open to GlassFish
>> in the future, it would save you tons of $$ and give you a better
>> environment to work with.... but I suspect that's not going to happen in
>> time for this project.  ;)
>>
>> *If* you still decide to go with JSF, my suggestion for the drill-down
>> case you mentioned (so Google indexes your page) would be as follows:
>>
>> 1) When rendering your table, write the links out via static text (not a
>> JSF button / link), for example:
>>
>>     <h:outputText escape="false" value="#{bean.linkHTML}" />
>>
>>     public String getLinkHTML() {
>>        return "<a href='/.../nextPage.jsf?prodId=" + productId +
>> "'>Product</a>";
>>     }
>>
>> 2) When you load the product from the database, get the "prodId" query
>> string parameter to see which record to load.
>>
>> This would allow indexing to work correctly and allow you to still use
>> JSF.
>>
>> Good luck!
>>
>> Ken
>>
>>
>>
>> James Perkins wrote:
>>
>> Great comments Ken thanks!
>>
>> Yes, the POST is going to be the biggest challenge. Having to think it
>> terms of how a search engine indexes is really hurting my brain :-). I'm so
>> used to just developing an application that has no need to care. We will
>> have some kind of category type drill down which probably would require JSF
>> links so that is my main concern.
>>
>> I'm not really to keen on creating static pages myself. It was the only
>> other thought I had at this point. I'm still researching some so we'll see
>> what happens.
>>
>> We can move to a Java EE 5 compliant server, but our client isn't on one
>> currently. The company I work for is an IBM business partner so we use
>> WebSphere Application Server. I know WAS 7.0 is Java EE 5 compliant, but my
>> boss didn't want to have to install it if we could get it running on WAS 6.1
>> since we already have a B2B app working on it.
>>
>> Again thanks for your expertise here.
>>
>> --
>> James R. Perkins
>> http://twitter.com/the_jamezp
>>
>>
>> On Fri, Jan 8, 2010 at 10:55, Ken Paulsen <Ken.Paulsen at sun.com> wrote:
>>
>>>
>>>
>>> James Perkins wrote:
>>>
>>> I'm getting ready to start the process of creating a consumer based web
>>> site. This is really the first time I've had to create a consumer based
>>> site. My original thought was I would JSF/Facelets to create the site, but
>>> got to thinking this might not work out so well as I need search engines to
>>> be able to index it.
>>>
>>>  Depends on how you do your navigation.  If you use POSTS for all your
>>> navigation (JSF makes this easy), then yes -- you'll likely have problems
>>> getting Google to index your site.  However, JSF can behave like many other
>>> frameworks which don't provide "navigation handler" type features, and you
>>> can simply do:
>>>
>>>     <a href="nextpage.jsf">Next Page</a>
>>>
>>> This will index fine with Google.  Used this way it's no different (nor
>>> is it any more helpful) than many of the other UI frameworks.
>>>
>>> The difficult areas would be if you were expecting a generated table of
>>> links / buttons AND you want them indexed by google... then you'd want JSF
>>> to generate them and then you're back to the POST or URLs which contain view
>>> state which google won't handle well.  You'd have to do extra work to make
>>> reproducible GET links in your table...
>>>
>>>  I've created web applications before, but they have always been internal
>>> applications or applications that required a user to log in and have an
>>> account.
>>>
>>> Doing some reading on SEO I'm seeing now that an entire JSF based site
>>> might not be the best approach. The main problem being you can't really
>>> bookmark JSF pages and links are mostly created using JavaScript which the
>>> spiders can't crawl.
>>>
>>>  I think the POST is mostly the issue.  Although some implementations of
>>> links/buttons do use JS that may also cause problems.  It's very easy to get
>>> around the JS-based components.
>>>
>>> My question is have others run into this? Are people really still
>>> creating static pages for stuff like this? Do any of you have suggestions on
>>> where to begin or possibly a framework that would work better than or with
>>> JSF? I've heard of PrettyFaces, but I think you have to be on a Java EE 5
>>> compliant server which to start we will not be running.
>>>
>>>  There is also RESTFaces and I think Seam has something and a couple
>>> others.  I'm not sure which is best, or if any are worth using (I haven't
>>> had this requirement either).  However, in the next version of JSF2 there
>>> will most likely be a standardized approach for REST URLs which should
>>> address most if not all of these issues.
>>>
>>> I've also considered creating a library to generate static pages based on
>>> templates. That way each time a new item or category is entered into the
>>> database a new page is not having to manually created and/or updated.
>>>
>>>  Yes that could be done too... although it would probably be just as easy
>>> to design your site to only use GET URLs and create custom components and/or
>>> use PrettyFaces (if it helps) for ensuring all URLs are generated the way
>>> you want them.  Generating pages gives you the overhead of manipulating
>>> files in your web tier and keeping it in-sync with your DB when content is
>>> removed or updated -- could be a pain.
>>>
>>> People's other suggestions might be worth exploring too... but there are
>>> a lot of benefits of JSF (this area is obviously not one of them).  Also,
>>> you said you would not be using a Java EE 5 server... does this mean JSF 2
>>> is out of the question?  I strongly recommend JSF 2 over previous versions
>>> of JSF.  Is this b/c of size?  Performance?  Hardware is incompatible?
>>> Unless your hardware isn't able to run the software, I would look seriously
>>> at Java EE 6 -- it's just better.  (If you hardware can't run modern
>>> software -- then you have bigger issues ;-) .)
>>>
>>> Anyway, good luck whatever you decide!
>>>
>>> Ken
>>>
>>>
>>> Thanks in advance,
>>> --
>>> James R. Perkins
>>> http://twitter.com/the_jamezp
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> Web Site - http://www.pjug.org/
>>> Javamail mailing listJavamail at pjug.orghttp://www.pjug.org/mailman/listinfo/javamail
>>>
>>>
>> ------------------------------
>>
>> _______________________________________________
>> Web Site - http://www.pjug.org/
>> Javamail mailing listJavamail at pjug.orghttp://www.pjug.org/mailman/listinfo/javamail
>>
>>
> ------------------------------
>
> _______________________________________________
> Web Site - http://www.pjug.org/
> Javamail mailing listJavamail at pjug.orghttp://www.pjug.org/mailman/listinfo/javamail
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.pjug.org/pipermail/javamail/attachments/20100108/d57851c0/attachment.html 