點入之後，顯示單一產品的資訊與簡介

編輯記錄

點選"我要購買"之後

編輯記錄

這是加入購物車之後的畫面

給商家用的線上商品上架作業

商家商品上架作業--->Client端的JavaScript程式碼編輯作業畫面001

編輯記錄

商家商品上架作業--->Client端的Javaforbidden程式碼編輯作業畫面002
透過Ajax技術把畫面資料回傳，並取得最新資料來更新畫面

編輯記錄

如果只是討論可行性 那麼您的作品一點問題都沒有 很OK 以下都是白講

想要推廣給程式師使用 必須要強調架構性 開發流程 維護性的東西 才有說服力
另外投入3RD開發工具 要面對的都是全球市場 否則沒啥意義
大家都會想要自己採用的工具 是可大可久 擴展性強
畢竟技術投入 都需要成本 一個不小心就會血本無歸

我說的Client指的是執行在瀏覽器裡的JS程式碼 是指RIA程式
不是瀏覽器本身 容易和server連結 大概是指Json 或websocket之類的通訊協定
瀏覽器一直在加速 平板手機運算能力也一直增強
RIA網頁早就勢不可擋 html5更是未來 傳統網頁早已過時

徹底分離是指開發分工模式
client端Html JS碼就在Dreamweaver frontpage 之類的工具中全數完成
可以輕易引用jquery YUI extjs 等強大框架
以一般UI來說 選單 對話視窗 下拉選單 分割頁框 只要懂css和jquery 不需要懂JS 也能完成工作
其實進入門檻很低

server就相當於AP server地位 這裡是Delphi k 當然是用Delphi
所有商業邏輯就寫在這
必須提供 json soap websocket 等接口 甚至自創協定也行 只是要提供
Client端的js lib以供呼叫

依我個人的愚見 Delphi 3RD攸關網頁市場 比較能做的 就只有AP server這一塊
我想表達的就只有這樣 或許是個人偏見 不喜莫怪~~

或許您的產品很有市場 我不了解
我尊敬每個產品的開創者 你們都很有毅力和勇氣 也祝你早日能成為付費元件
-------------------------------------------------------------------------------------
以前試用類似Delphi元件的心得:
1. 用Delphi作網頁UI 畫面 受限於元件屬性 做出來質感不佳
2. 設計階段和執行 畫面有落差
3.把數百行 甚至過千行的JS程式碼 存在DFM檔裡 一個不小心
動到某個畫面上的元件 就全沒了?
4.改動個小排版 就需要重新編譯整個程式 然後再發布 很沒效率
5.自行寫在VCL元件的JS 碼 除錯困難?
6.自行提供html樣板檔 樣板怎麼來?是不是要回到 dreamweaver路線..
那說好的Delphi UI畫面設計呢?

評估幾天後 結論是採用樣板檔 比較能掌控 但又失去使用套件的意義 整個放棄

===================引 用 JL9168 文 章===================
>>不知為何 新開發的東西 為何走回cgi/isapi的老路?
如果這樣是老路，那ASP.NET與PHP都是很老的東西了，因為它們都是Base On ISAPI
如果要說"老"，那Javascript不也是也很老的技術了嗎? 那HTML不就是廢柴??
更何況重點不在用了什麼，而是產出什麼!!

>>如果要說亮點 應該是可以用Delphi做網頁 就如此而已
這裡是Delphi KTop，這就是我們所以在此討論以Delphi做網頁的原因!!
當然，用C,C 甚至是VB也可以做出這類的產品

>>那回到類似產品的點 Intraweb ,zk 的完整度 知名度不是更高 ?
>>乍看之下十分驚人 但最後也是小眾市場
每個技術、每個套件都有優缺點，但看用的人想用什麼來產出成品吧?

>>不應該
>>"認為使用者不懂Javascript Html"
>>"最好不要讓使用者摸到JS html "
>>"企圖讓使用者使用單一語言完成前後端"

我們知道Javascript對某些人來說不難，不過這只是對不懂的人實做一個貼心、簡單、便捷的工具而已!!
之前的文章也說了，這個套件不是只有用Delphi寫前端；更可以用Javascript完成前端動作!!
真的沒有只用單一語言完成前後端，像Ajax技術不是Delphi能做的吧??

>>應該
>>"Server 和Client 徹底分離"
什麼樣的做法才叫徹底分離? Web Server和瀏覽器分離的還不夠??

>>"Client部份為純Javascript 像jquery ,etxjs "
既然是要純Javascript，那肯定不要HTML與DHTML、XML、CSS ....這些都不需要了，是嗎?
不過這樣Web程式會很難寫，而且我們知道jQuery、extjs也沒有不用除了JavaScript以外的技術!!

>>"Server 部份 純Delphi 偏向遠端methed ,商業邏輯 程式碼的管理開發"
這個套件並沒有限制邏輯一定要在遠端，想寫在Javascript然後再引入到Client端也行；
不是很清楚你想表達什麼，不過這個套件並不干涉使用者如何處理這類的問題!!

>>"Server 和Client容易連結"
何謂"Server 和Client容易連結" ? Http Server 和 瀏覽器有容易連結和不容易連結的問題??
我們還是第一次聽到這種說法，是蠻有創意的；不過無法理解!!

>>建議:
>>既然用Delphi 開發 應著重在server side商業邏輯程式碼"管理"

"管理" 商業邏輯程式碼是要做什麼用途??版本控制??
還是不清楚你想表達什麼，不過這個套件並不干涉使用者如何處理這類的問題!!
我們不想把重點放在這上面，因為這不是程式管理系統或是版本控制套件!!

>>像 if xxx='開始' then begin
>>這樣寫 看起來就很弱

那Javascript不就要唾棄使用if .... then,所有的高階程式語言包括Javascript/VBScript都很弱囉??
這是這句話的意思嗎??

>>應該用Interface 等程式技巧 包裝的更漂亮一些
我們覺得這不是我們所在意的，系統好不好用不會因為包裝了Interface而有所差別，
而且太多Interface對某些開發者來說真的不是那麼好理解與使用；只是於軟體工程好看而已!!
要學的東西太多，我們不想因為這個東西，給我們的客戶太多學習門檻。


以上，單純就事論事；沒有絲毫惡意，望您海涵。

謝謝你的祝福，非常感謝!!


===================引 用 leveon 文 章===================
先說沒有惡意 我也沒試用過

>>如果只是討論可行性 那麼您的作品一點問題都沒有 很OK 以下都是白講 
>>想要推廣給程式師使用 必須要強調架構性 開發流程 維護性的東西 才有說服力

每個類型的產品都有它們的架構與標準SOP，是否應該互相比較；我們覺得不是那麼有需要
只要是系統或架構，都是具備某種程度的維護性；差異在於....要花多少投資和時間。

>>另外投入3RD開發工具 要面對的都是全球市場 否則沒啥意義
>>大家都會想要自己採用的工具 是可大可久 擴展性強
>>畢竟技術投入 都需要成本 一個不小心就會血本無歸

如果要據實而論，那必須說；"這個領域沒有永遠可大可久或擁有無限拓展性的東西與技術"
這就是我們追求可行性而不是追求理想的原因，因為可大可久擴展性強意味著"成本無上限"
那目前的投資何時才是回收的時機?? 誰有能力這樣撐下去，答案是....沒有!!

把目前的投資最大化，取得資源之後；才會有繼續往下走的動力!!

>>我說的Client指的是執行在瀏覽器裡的JS程式碼 是指RIA程式
>>不是瀏覽器本身 容易和server連結 大概是指Json 或websocket之類的通訊協定
>>瀏覽器一直在加速 平板手機運算能力也一直增強
>>RIA網頁早就勢不可擋 html5更是未來 傳統網頁早已過時

其實我們是覺得你先前說的太簡略，應該要詳細陳述；所以故意這樣說這樣問，不過必須
要說的是沒有所謂舊的東西和舊的技術，HTML5就是源自HTML、Json就是源自XML
是舊是新，不過是心理作用；更重要的是，說到底要作什麼應用；這些技術是否到了該取
代市場上現有的一切應用? 否則只是在畫餅，就算平板手機運算能力一直增強，但是強過
伺服器了嗎? 手機或平板的websocket Service能取代伺服器嗎? 不必說也有答案。
就算不用這些在手機或平板電腦上，一樣可以用網頁程式做到這些啊，另外說到Web RIA
再強也強不過和設備整合度高的Native App......

>>徹底分離是指開發分工模式
>>client端Html JS碼就在Dreamweaver frontpage 之類的工具中全數完成
>>可以輕易引用jquery YUI extjs 等強大框架
>>以一般UI來說 選單 對話視窗 下拉選單 分割頁框 只要懂css和jquery 不需要懂JS 也能完成工作
>>其實進入門檻很低

開發分工模式，意味著需要不同的人力；意味著老闆需要聘用不同領域的人力。即使是外包好了
還是意味著增加了開發成本。當然如果有人會所有的東西，這當然是很棒，既然Dreamweaver frontpage
這些工具把畫面、程式都寫完了甚至是引用jquery YUI extjs 等強大框架；那還需要什麼開發分工模式?
一個工具就做完了不是嗎?

使用jquery不需要懂JS也能完成工作，Maybe是這樣；不過很令人存疑，不懂JS的人會使用Base On JS的
程式..........至少要懂得JS的基礎，甚至了解JS的物件基礎，遇到使用上的問題才能排除問題吧?
當然如果公司人多，分工可以細到這種程度，那只能說很幸運也很不幸。

>>server就相當於AP server地位 這裡是Delphi k 當然是用Delphi
>>所有商業邏輯就寫在這
>>必須提供 json soap websocket 等接口 甚至自創協定也行 只是要提供
>>Client端的js lib以供呼叫

這樣又是不同的架構了，聽起來就是WebSphere之類的架構；不過如果一個簡單的WebAP就可以
解決的需求，又何需大費周章? 既增加成本又增加困難度；這也是國外一些工具軟體公司最另
人詬病的地方-----永遠是技術的投資，但是用來幹什麼，對不起，請自行想辦法

更何況，Ap Server還有效能的問題，還有安全性的問題；自製的協定是否有不為人知的漏洞
這樣的東西出門了，穩定嗎?? 拿什麼說服使用者或是要接手維護的MIS人員? 認證?? 測試數據??

>>依我個人的愚見 Delphi 3RD攸關網頁市場 比較能做的 就只有AP server這一塊
>>我想表達的就只有這樣 或許是個人偏見 不喜莫怪~~

既然覺得是個人偏見，我們並不多說什麼；只是覺得你沒有去了解這個東西的目標和使用目的之前
就要去評論去議定一個可行的方案，態度上有欠公允；你當然有權不喜歡Delphi、不欣賞你不認同
的技術，不過沒有去接觸了解就下結論實在是令人難以茍同；更何況你後來陳述出來的某些方式和
當前的做法是另一種不相同的思維。我們想告訴你的是，能做出產品取得利潤讓公司賺錢的技術都
是可以使用並且投資的技術，使用者也不會去過問；當然除非他們指定了那些方式。但這些並不足
以讓工程師去看不起或認為是過時的技術，技術的本質就只是工具而已。


>>以前試用類似Delphi元件的心得:
>>1. 用Delphi作網頁UI畫面受限於元件屬性做出來質感不佳
據我們所知，網頁畫面還有CSS還有美工可以加強此類的質感問題，這類的
問題應該不是只能都全怪給元件吧?? 配色、畫面編排、設計感，都是影響要素
元件應該也不可能管到這類的問題，這是設計者應該要花心思去學習的地方。
以筆者寫PHP的朋友來說，做出另人激賞的成果的大有人在。

>>2. 設計階段和執行 畫面有落差
這要看你是否覺得這樣的落差是否還能忍受，但不代表所有相關的套件都不好。

>>3.把數百行 甚至過千行的JS程式碼 存在DFM檔裡 一個不小心
>> 動到某個畫面上的元件 就全沒了?
連Word、Excel文書處理軟體都會因為忘記備份或存檔而有這樣的問題了，你覺得
這樣的問題該算在工具軟體的頭上嗎?? 人為的不小心不可以歸咎於工具吧??

>>4.改動個小排版就需要重新編譯整個程式然後再發布很沒效率
這是工具性質的不同了，編譯器和直譯器天生體質就不同；硬要拿來比較，沒道理也沒必要
要看使用者需求來決定用什麼技術解決什麼問題。

>>5.自行寫在VCL元件的JS 碼 除錯困難?
自有JavaScript以來，除錯就一直很困難；這已經不是新聞了，當然困難也有困難的解法，
就我們這個套件來說，這就是提供公用JS函式庫的原因(至少我們除錯過了，使用者不需要擔心)


>>6.自行提供html樣板檔 樣板怎麼來?是不是要回到 dreamweaver路線..
>> 那說好的Delphi UI畫面設計呢?
>> 評估幾天後 結論是採用樣板檔 比較能掌控 但又失去使用套件的意義 整個放棄

我們這個套件的樣版檔就是以Delphi IDE來設計之後再行轉出的。所以沒有這類的問題。
很感謝你給這個機會讓我們來說明。也讓我們的工程師動動頭腦釐清想法。

編輯記錄

感覺我是亂入

軟體的價值在於1.是否客戶看到他們要的，2.客戶願意花多少預算

其次，架構只有在作業環境改變了，重要性才會顯現；客戶會因為架構而多給錢? 不太可能

是輸是贏其實沒什麼定論，本來就不是重點；重要的是這個東西的出發點和訴求
每個東西都有其存在的目的，只是覺得不需要把不同方向的東西都混為一談。
還要去說孰優孰劣，委實多餘了。

如果言論不需要去負責，那話是怎麼說都行，不是嗎?

學道有先後，術業有專攻。這是很平常不過的道理。

Delphier有些對Web技術的涉獵不廣並不代表他們落後，而是沒有急迫的業務上需求
這中間有很多人把時間花在讓公司能立即獲利的事情或是滿足企業的需求之上。

很多東西一開始只是要解決公司內部自己遇到的問題，當然不見得市場很廣；更
何況開發工具與套件的市場又不同於一般市場；主觀的認定會有一定的影響力。

所以能用較少的成本來立即達到需要轉換不同工具且耗費大量轉換成本，才能做到的成果，
這才顯現出它的價值，然而，選擇還是得看決策者。

-----------------------------------------------------------------------------------

>>"把自己當成是Delphi的外行人"
>>"跳脫Delphi win32的設計思維去設計網頁框架"
>>"以phper asper xxxer 看了會想進來用"當作是產品目標"

其實這已經是另外一件事了，這也是後面我們需要努力以赴的另一個課題。

-----------------------------------------------------------------------------------

我們只是想強調沒有任何技術是需要被說成落後或是好不好。技術就是技術嗎!!
相信你也是如此吧?

這些不見得都是嘴砲，我們有得到一些很實在的東西；還是要感謝你!!

很欣賞您的態度 軟體原本就是漸進式發展
爆發期往往只發生在一瞬間 能堅持住才有成功機會

您的附件我下載看了
建議
1.多放Delphi 2007 ,XE XE2等比較風行的版本
2.請附加Demo作品檔 得到的回響會比較大
3.一張一張圖貼在論壇說明概念 讓人不易理解
製成動畫檔GIF 或flash 效果會比較好
4.請自帶一個ISAPI的web server,Demo或除錯效果會比較好
5.發現您的作品和 http://www.realthinclient.com
的互補性很強 建議搭配他的免費版web server

http://sourceforge.net/projects/rtcsdk/files/latest/download

期待您開新帖再推出~

其實在一來一往之間，你也給了我們很多想法；有些甚至是目前正在跟幾位開發人員討論中

目前Demo的部份已經累計到30多個Example，更有甚者會加入一些系統性的Demo

目前已經有一個HttpServer的產品可以用來配合這個套件

感謝你抽空和我們討論這麼多，我們會儘快更新相關的資料!!


===================引 用 leveon 文 章===================
很欣賞您的態度 軟體原本就是漸進式發展
爆發期往往只發生在一瞬間 能堅持住才有成功機會

您的附件我下載看了
建議
1.多放Delphi 2007 ,XE XE2等比較風行的版本
2.請附加Demo作品檔 得到的回響會比較大
3.一張一張圖貼在論壇說明概念 讓人不易理解
製成動畫檔GIF 或flash 效果會比較好
4.請自帶一個ISAPI的web server,Demo或除錯效果會比較好
5.發現您的作品和 http://www.realthinclient.com
的互補性很強 建議搭配他的免費版web server

http://sourceforge.net/projects/rtcsdk/files/latest/download

期待您開新帖再推出~

下面是一個最近在撰寫中的Demo

目前的版本功能說明:

到目前為止，這個套件已經可以大量地支援JS；並且支援瀏覽器Client端元件的開發，以下為Example
Example:
目的名稱-->以VCL來開發計算體積的HTML元件
預計結果如下圖所示

編輯記錄

HTML元件執行的結果，如下:

元件設計過程(一) ，新增元件的UI畫面

元件設計過程(二)，撰寫計算體積的JS程式碼

元件設計過程(三)，撰寫按鈕按下之後的JS程式碼

所以可以做到以VCL元件來創造出各類型的HTML元件了，這也是很重要的一步!!
也就是說可以藉由這樣的方式來達到Web RIA 的開發，不必什麼都自己從零做起!!

另外，最新的企業版也開始導入結合Ajax技術來開發HTML元件的技術(已經完成了)
正式步入Delphi IDE for Web RIA開發的里程碑，往後再發文說明這個部份

至此，這個框架模組已經告一段落，接下來是標準Web RIA 延伸控制項套件的開發；接下來將陸續
針對各類功能與開發過程進行介紹。

第一個以Delphi IDE開發的Ajax萬年曆元件(參照下圖)
不需要換頁，就能置換每月日期資訊(以Ajax處理)，並且在選擇了日期時，也以Ajax模式回傳選擇日期。

此外，企業版還加入了避免駭客解析瀏覽器前端HTML文件的"高度加密模式"；並隱藏一些公用的JS函式
讓每個Client端的JS公用函式都不同，卻保持著一樣的功能

編輯記錄

另外一個亮點是，企業版的架構上多了RunTimeObject Init Function 以及 RunTimeObject Release Function
這個好處是可以解決以往動態產生網頁後；相關的物件就必須要釋放，只能實做Stateless的作法。

新的架構支援有狀態物件的實做，只要很簡單的幾道程式碼；就可以達到Win Ap有狀態物件的實作，讓WebApp
開發起來更像Win App了。

底下就是這個架構的實做框架
Library WebRunTimeObjModeApp;
uses
Windows,
SysUtils,
Classes,
Forms,
ISAPI2,
UAdv_ISAPI_Utils,
UAdv_PUBLIC_Types;

//ISAPI Main procedures !!
procedure WebAppUIUpdateProc( WebSession:TAdv_WebSession
;InWebPage,InCtrl,InCtrlClass,InCtrlData:string);
begin
with WebSession do
begin

end;//with...end!!
end;

procedure WebAppInitProc(WebSession:TAdv_WebSession;InInitParams:string;DynamicOwner:TComponent);
begin
WebSession.AutoCheckUIResources := TRUE;
with WebSession do
begin

end;//with...end!!
end;

procedure WebAppReleaseProc(WebSession:TAdv_WebSession);
begin
with WebSession do
begin

end;//with...end!!
end;

procedure WebAjaxEventProc(WebSession:TAdv_WebSession;var RunWebMain:boolean);
begin
with WebSession do
begin

end;//with...end!!
end;

procedure WebRunTimeOBJInitProc( var RunWebMainAfterProc:boolean
;var RunUnitCoreEventAfterProc:boolean);
begin
ADO_InitADOObject;
//---------------------------------------------------

end;

procedure WebRunTimeOBJReleaseProc( var RunWebMainAfterProc:boolean
;var RunUnitCoreEventAfterProc:boolean);
begin
ADO_ReleaseADOObject;
//---------------------------------------------------

end;

procedure WebAppMain(WebSession:TAdv_WebSession;Request:TPub_Request;Response:TPub_Response);
begin

end;

function HttpExtensionProc(var ECB:TEXTENSION_CONTROL_BLOCK):DWORD; stdcall;
begin
result := DoHttpExtensionProc( Application,'EMPTY-PARAMS',WebAppMain
,WebAppInitProc,WebAppReleaseProc
,WebAjaxEventProc,WebAppUIUpdateProc
,ECB);
end;

/////////////////////////////////////////////////////////////////////////////////

Exports
HttpExtensionProc;

/////////////////////////////////////////////////////////////////////////////////

//--------------------------------------------------------------
var RunTimeApp:TAdv_RunTimeApplication;
//--------------------------------------------------------------

procedure DLLMainProc(Reason: integer);
begin
case Reason of
//*************************************************************//
DLL_PROCESS_ATTACH://DLL程式初始化!!--->DLL Create()
begin
//--------------------------------------------------------------------------------------
RunTimeApp
:= TAdv_RunTimeApplication.Create( FALSE
,WebRunTimeOBJInitProc
,WebRunTimeOBJReleaseProc);
RunTimeApp.StartRunTimeApplication;
//--------------------------------------------------------------------------------------
end;
//*************************************************************//
DLL_PROCESS_DETACH://DLL程式結束釋放!!--->DLL Destroy()
begin

//-------------------------------------------------
RunTimeApp.EndRunTimeApplication;
//-------------------------------------------------
end;
//*************************************************************//
DLL_THREAD_ATTACH:
begin

end;
//*************************************************************//
DLL_THREAD_DETACH:
begin

end;
end;//case...end!!
end;

begin
//---------------------------------------------------------------------------------
DllProc := @DLLMainProc;
DLLMainProc(DLL_PROCESS_ATTACH);
//---------------------------------------------------------------------------------
end.

編輯記錄

舉個例子，假設我們在WebApp中用ADO 抓取某一特定的資料，然後要逐筆維護，這需要寫多少關於資料操作的程式碼?
只要實作RunTime OBJ的機制，就不需要去Release ADO OBJ然後再重新開啟，尋找剛才使用者要修改的那一筆，
我們就可以在事件中下 ADOQry.Edit;.........ADOQry.Post; 這樣下來節省了許多開發的時間。

另外，具狀態物件在模組中又可以區分為: 1.公用的具狀態物件，2.By Client 建立的動態具狀態物件
可以依照系統開發的需要來分別使用。
例如:
資料庫的Connection物件可以做為公用的具狀態物件，並於使用者登入時，指定給使用者的ClientDataModule。

而使用者的DataModule可以依照選用的功能，建立不同的資料模組物件來使用。

現在要說明如何製作簡易的CSS特效，這個特效就是當滑鼠移動或移出控制項時；控制
項的顏色與字體顏色會變化。

首先，我們先把程式的畫面作到如下圖所示(基礎的部份，我們不再重複):

接著，把該控制項(TAdv_HTML_Label)的字體垂直位置屬性TextYOffset設定為1.65；如下圖所示

這個屬性用來調整TAdb_HTML_Label的文字位置，調整值要視字型和字體大小決定。

接著，把該控制項的屬性( UIEffectWithScript )設定為TRUE；如下圖所示